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FOREWORD 

The  Office  of  the  Manager,  National  Communications  System,  is  assigned  the 
management  of  the  Federal  Telecommunication  Standards  Program,  which  is  an 
element  of  the  overall  General  Services  Administration's  (GSA's)  Federal 
Standardization  Program.  Under  this  program,  the  NCS,  with  the  assistance  of 
the  Federal  Telecommunication  Standards  Committee,  identifies,  develops,  and 
coordinates  proposed  Federal  Standards  which  either  contribute  to  the  inter¬ 
operability  of  functionally  similar  Federal  telecommunication  systems,  or  to 
the  achievement  of  a  compatible  and  efficient  interface  between  computer  and 
telecommunication  systems.  In  developing  and  coordinating  these  standards,  a 
considerable  amount  of  effort  is  expended  in  initiating  and  pursuing  joint 
standards  development  efforts  with  appropriate  technical  committees  of  the 
Electronic  Industries  Association,  the  American  National  Standards  Institute, 
the  International  Organization  for  Standardization,  and  the  International 
Telecommunication  Union.  This  Technical  Information  Bulletin  discusses  the 
current  status  of  certain  CCITT  draft  recommendations  relating  to  proposed 
Integrated  Services  Digital  Networks  (ISDNs).  (The  explanatory  material  on 
pages  1-20  of  this  TIB  was  written  by  Frank  McClelland,  Electronics  Engineer; 
the  TIB  was  compiled,  edited,  and  published  by  Janet  M.  Orndorff,  Editorial 
Assistant.)  Comments  or  statements  of  requirements  that  would  assist  in  the 
advancement  of  this  work  are  welcome  and  should  be  addressed  to: 

Office  of  the  Manager 
National  Communications  System 
ATTN:  NCS-TS 
Washington,  DC  20305 

Telephone--Commercial:  (202)  692-2124 
AUTOVON:  222-2124 

FTS:  692-2124 
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1.  INTRODUCTION. 


The  purpose  of  this  Technical  Information  Bulletin  is  to  report  to  the  FTSC 
(Federal  Telecommunications  Standards  Committee)  work  done  on  the  major  CCITT 
(International  Telegraph  and  Telephone  Consultative  Committee)  recommendations 
on  Integrated  Services  Digital  Networks  at  meetings  in  November  and  December 
1983.  The  first  part  of  this  TIB  gives  an  overview  of  the  10  recommendations 
from  these  meetings  while  the  appendix  contains  the  text  of  the  actual 
recommendations.  The  recommendations  are  in  draft  form  and  have  not  been 
approved  by  the  complete  study  groups  concerned,  but  will  be  used  by  some 
manufactures  to  start  preliminary  development  of  ISDN  equipment.  Also 
included  in  this  TIB,  as  section  5,  is  a  glossary  of  most  of  the  commonly  used 
ISDN  terms.  Figure  1,  based  on  draft  Recommendation  1.411,  which  was  not 
considered  at  these  meetings,  shows  the  interface  points  at  the  user's 
premises,  for  reference  in  reading  other  recommendations. 

2.  BACKGROUND. 

The  term  Integrated  Services  Digital  Network  is  used  to  describe  a  network 
having  digital  transmission  and  supporting  most  of  the  telecommunications 
services  presently  provided  by  separate  dedicated  networks,  such  as  analog 
telephony,  telex,  and  message  switching.  The  practicality  of  incorporating 
all  such  services  in  a  single  network  arises  from  the  rapidly  decreasing  costs 
of  both  digital  transmission  and  digital  processors.  As  can  be  seen  from 
examining  the  draft  recommendations,  such  an  approach  is  economically  viable 
only  if  simple  digital  processors  are  very  inexpensive,  since  even  a  digital 
telephone  must  include  an  amount  of  processing  logic  that  would  have  been 
considered  large  ten  years  ago. 

In  spite  of  the  giant  technical  steps  that  must  be  taken  to  design,  develop, 
and  implement  ISDN  equipment  and  networks,  it  is  expected  that  the  present 
telephone  networks  in  most  of  the  world  will  start  evolving  toward  ISDNs 
within  a  few  years--probably  within  three  or  four  years.  ISDN-like  PABXs 
(private  branch  exchanges)  will  be  available  possibly  within  one  or  two  years 
after  the  CCITT  recommendations  are  approved  at  plenary  meetings  next  year. 

The  word  "like"  qualifies  ISDN  because  many  of  the  first  products  will  not 
have  all  the  characteristics  and  features  that  are  desribed  in  the 
recommendations  and  that  will  ultimately  become  standard  throughout  the 
world.  It  is  expected,  however,  that  the  first  systems  will  have  64  kbit/s 
channels  that  can  carry  either  digitally  encoded  speech  or  other  data, 
out-of-band  signalling  by  a  separate  channel  that  operates  in  a 
packet- switching  mode,  and  possible  other  data  channels.  Until  present  56 
kbit/s  transmission  equipment  in  the  U.S.A.  is  converted  to  64  kbits/s,  some 
equipment  sold  may  operate  at  56  kbit/s.  (Most  56  kbit/s  channels  in  the 
U.S.A.  actually  transmit  64  kbit/s,  but  8  kbit/s  are  reserved  for  signalling 
and  for  insuring  enough  electrical  transitions  to  maintain  timing  at  repeater 
stations.  A  new  digital  encoding  technique,  called  B8ZS  and  described  in 
Recommendation  G.703,  will  take  care  of  the  timing  problem,  and  the  signalling 
can  be  carried  on  the  ISDN  separate  out-of-band  signalling  channel.) 

Although  not  specifically  related  to  the  forthcoming  ISDNs,  a  draft 
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recommendation,  G.7zz  (zz  numbers  to  be  assigned  later),  prepared  at  these 
meetings  describes  a  32  kbit/s  adaptive  differential  pulse  code  modulation 
(ADPCM)  voice  encoding  algorithm  that  may  ultimately  influence  the  way  the 
ISDN  64  kbit/s  channel  is  used,  as,  for  example,  being  subdivided  into  two 
channels.  The  32  kbit/s  draft  recommendation  specifies  the  encoding  from  a  A 
or  mu  law  channel  operating  at  64  kbits/s  to  the  new  32  kbit/s  encoding. 
However,  the  first  step  in  the  encoder  is  to  convert  the  A  or  mu  law  signal  to 
a  uniform  PCM  (pulse  code  modulated)  signal,  which  could  also  be  the  input 
from  a  voice  A/D  (analog  to  digital)  encoder.  The  32  kbit/s  algorithm  is 
specified  in  such  detail  that  it  can  be  implemented  unambiguously  by  several 
manufacturers  without  any  change  in  quality  of  reproduction.  For  example,  at 
each  step,  the  accuracy  of  the  digital  conversion  is  specified  in  number  of 
binary  bits,  their  format  (fixed  or  floating  point),  and  the  division  of  the 
bits  between  mantissa  and  characteristic,  if  floating  point.  This  draft 
recommendation  and  an  accompanying  report  from  the  developing  committee  will 
be  distributed  separately  to  members  of  the  FTSC. 

Recommendations  for  this  CCITT  Study  Period  (1981  -  1984)  will  be  approved  at 
plenary  meetings  in  1984  and  published  in  bound  volumes,  which  will  be  known 
as  Red  Books  for  the  color  of  their  covers.  As  a  general  rule, 
recommendations  are  not  formally  approved  and  published  except  at  the  end  of 
study  periods,  so  these  recommendations  will  remain  in  force  until  1988.  In 
cases  of  urgency,  it  is  possible  to  approve  recommendations  within  a  study 
period  by  means  of  expedited  procedures,  but  this  method  is  rarely  used  since 
it  introduces  too  much  uncertainty  for  manufacturers  and  implementers.  Study 
Group  XVIII  ISDN  Working  Teams  will  meet  again  in  February,  in  Brazil,  to 
finalize  their  draft  recommendations  before  they  are  presented  to  the  Study 
Group  XVIII  plenary  for  approval,  probably  in  May  1984.  Working  Group  6  of 
Study  Group  XI,  which  is  developing  the  layer  2  and  layer  3  protocols  for  the 
signalling  channel,  is  not  scheduled  to  meet  until  the  Study  Group  XI  plenary, 
also  probably  to  be  held  in  May  1984.  Since  Study  Group  XVIII  has  requested 
extensive  changes  in  the  current  draft  of  the  layer  3  protocol  (Q.930),  it  is 
possible  that  an  attempt  will  be  made  to  schedule  a  meeting  of  a  portion  of 
Working  Party  XI/6  to  deal  only  with  Q.930  before  that  time.  In  any  event, 
substantial  extentions  to  and  changes  of  the  Study  Period  1981  -  1984 
recommendations  should  be  expected  in  Study  Period  1985  -  1988. 

3.  TYPES  OF  ISDN  RECOMMENDATIONS. 

CCITT  recommdations  are  written  in  a  style  similar  to  standards,  as,  for 
example,  those  published  by  the  American  National  Standards  Institute.  They 
are  called  recommendations  rather  than  standards  so  that  it  is  clear  that 
their  use  is  entirely  up  to  individual  countries  and  companies.  (The  CCITT  is 
part  of  the  International  Telecommunications  Union,  an  organization  of  the 
United  Nations.)  Although  it  is  often  said  that  CCITT  recommendations  need 
only  address  matters  concerning  interoperation  between  networks  in  different 
countries,  it  has  been  found  practical  with  modern  digital  networks  to  specify 
also  the  customer- network  interface.  This  allows  equipment  manufacturers  to 
have  product  lines  that  are  compatible  with  most  national  networks,  allows 
users  to  transport  equipment  between  networks,  and  helps  in  developing  network 
internal  protocols  that  require  minimum  format  conversion  at  the 
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user- to- network  interface.  In  fact,  in  the  case  of  the  widely-used 
Recommendation  X.25,  for  packet-switching  services,  the  customer-to-network 
interface  was  specified  several  years  before  the  network-to-network  interface 
was  specified. 


For  convenience  in  discussing  them,  the  ISDN  recommendations  included  in  this 
TIB  can  be  considered  as  being  grouped  into  three  categories.  The  first  group 
specifies  what  the  ISDN  is  to  do  in  terms  of  services  that  are  visible  to  the 
user.  The  second  group  specifies  the  network  architectural  features  on  which 
the  recommendations  are  based.  The  third  group  specifies  the  electrical 
characteristics  and  protocols  that  are  to  be  used.  The  grouping  is  not 
precise  in  that  some  recommendations  cannot  be  assigned  exactly  to  one  of  the 
three  groups,  in  which  case  arbitrary  choices  are  made  (for  example,  with  the 
numbering  plan),  but  it  should  aid  the  reader  in  sorting  out  the  large  amount 
of  detail  contained  in  the  recommendations.  A  listing  of  the  recommendations 
in  each  category  follows  at  the  end  of  this  section. 


One  area  of  importance  that  is  not  included  in  this  TIB  is  that  of  the 
protocols  on  the  out-of-band  signalling  channels  between  network  switches.  It 
is  expected  that  these  signalling  protocols  will  be  from  CCITT  Signalling 
System  Number  7  (present  version  specified  in  Recommendations  Q.701  through 
Q.741),  but  there  may  be  some  different  signalling  messages  developed  to 
support  the  ISDN  services.  It  is  an  objective  to  have  the  signalling  messages 
on  the  user-to-network  signalling  channel  match  as  closely  as  possible  those 
of  the  ISDN  part  of  Signalling  System  Number  7  to  reduce  protocol  conversion 
processing  at  the  terminating  switches.  The  user-to-network  protocols  are 
described  in  draft  Recommendation  Q.930,  which  is  discussed  in  detail  in 
$  4.11. 


The  following  ISDN  draft  recommendations  are  discussed  in  more  detail  in  ^  4 
of  this  TIB  and  are  reproduced  in  the  appendix. 


ISDN  Draft  Recommendations  Relating  to  Services  Offered  the  User. 
r.200  Services  Supported  by  an  ISDN 
I.2xx  Bearer  Services  Supported  by  an  ISDN 
1.320  Addressing  and  Numbering  Principles  in  ISDN 
1.325  (I.3xx  was  designation  before  xx  was  replaced  by  25)  ISDN 
Connection  Types 


-^P-_Dr?-^.^^coni'niien<:*j^^ons  Rating  to  Architectural  Models. 

1.300  ISDN  Network  Functional  Principles 

1.310  ISDN  Functional  Architecture  Model — Part  A:  Functional  Model 

1.311  ISDN  Protocol  Reference  Model 


ISDN  Draft  Recommendations  Relating  to  Electrical  Characteristics  and 
Protocols  at  the  IJser-to- Network  Interface.  ” 

1.431  Basic  User/Network  Interface  -  Layer  1  Specifications 

1.432  Primary  Rate  User/Network  Interface  -  Layer  1  Specifications 
Q.920  (1.441)  Specification  of  the  ISDN  User-Network  Interface  Data 

Link  Layer  Protocol 


WWW 


m 

/V  Q.930  (1.457)  Specification  of  the  ISDN  User-Network  Interface  Layer 

v*  3  Protocol 

V/>  Note:  Q  designations  are  given  hy  Study  Group  XI;  I  designations  are 

,vvj  those  by  which  recommendation  is  known  in  Study  Group  XVIII. 


4.  BRIEF  DESCRIPTIONS  OF  RECOMMENDATIONS. 

In  the  following  sections,  a  brief  abstract  will  he  given  of  the  contents  of 
each  of  the  recommendations  listed  at  the  end  of  §  3.  The  purpose  is  to  give 
the  reader  an  overview  of  the  type  of  material  covered  in  each  draft 
recommendation  so  that  specific  recommendations  can  be  selected  for  more 
thorough  study,  if  desired.  Thus,  these  abstracts  should  be  used  as 
descriptions  of  the  content  only,  and  reference  to  the  actual  recommendations 
should  be  made  for  definitive,  "official"  specifications.  The  layers 
referenced  in  the  descriptions  are  the  layer  in  the  Open  Systems 
Interconnection  architectural  model  developed  by  CCITT  and  by  ISO.  A 
particular  protocol  may  overlap  somewhat  between  layers,  but,  in  general,  the 
data  link  layer  corresponds  to  layer  2  and  the  network  layer  to  layer  3. 


4.1.  1.200 — Services  Supported  by  an  ISDN.  (Revised  at  November  1983  Meeting 
of  Working  Teams  2,  3,  and  4  of  Study  Group  XVIII.) 

Draft  Recommendation  1.200  describes  the  types  of  services  offered  by  an  ISDN, 
rather  than  the  services  themselves.  Although  the  recommendation  does  not 
supply  much  information  to  the  user  about  what  specific  services  he  can  obtain 
from  an  ISDN,  it  does  establish  principles  that  will  allow  other  more  specific 
recommendations  to  establish  boundaries  between  services  so  that  they  can  be 
provided  by  different  entities,  such  as  private  packet  switching  networks.  A 
fundamental  feature  of  ISDNs  is  that  a  few  connection  types  can  support  a 
variety  of  services. 

There  are  two  general  types  of  services  offered  by  an  ISDN,  bearer  services 
and  teleservices.  Bearer  services  are  the  basic  connection  services  between 
users  or  between  a  user  and  a  supplier  of  a  higher  service,  such  as  a  packet 
switch  external  to  the  ISDN.  In  Recommendation  1.200,  bearer  services  are 
discussed  in  terms  of  layers  of  the  Open  System  Interconnection  model, 
specified  in  Recommendation  X.200  (of  Study  Group  VII,  not  an  ISDN 
recommendation).  These  layers  are  discussed  in  more  detail  in  §4.5,  below. 
Bearer  services  utilize  only  the  physical  layer  functions,  and  possible  the 
data  link  and  network  layer  functions.  A  bearer  service  is  composed  of  a 
basic  bearer  service  and  possibly  optional  supplementary  bearer  services.  A 
bearer  service  offered  by  a  particular  provider,  such  as  a  local  operating 
company,  will  include  functions  from  the  first  three  OSI  (Open  Systems 
Interconnection)  layers,  but  may  not  include  all  of  the  functions  possible. 

The  additional  functions  are  called  ALFs  (additional  lower  layer  functions) 
and  can  be  offered  by  other  providers  or  by  the  terminal  itself. 

More  elaborate  services,  as,  for  example,  telex  service,  involve  higher  layers 
of  the  OSI  model  and  are  called  teleservices,  which  were  referred  to  as 
telecommunication  services  in  previous  drafts  of  ISDN  recommendations.  It  is 
in  this  category  that  decisions  on  definitions  become  difficult  because  of  the 
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conflicting  interests  between  groups  that  want  to  provide  for  competitive 
offerings  of  such  services  (in  the  U.S.A.,  for  example)  and  groups  that  do  not 
want  to  encourage  offering  these  services  by  providers  outside  the  national 
telecommunication  network.  Decisions  are  also  complicated  by  the  desire  of 
some  telecommunication  offers  to  charge  different  tariffs  for  the  same 
connections  when  used  for  different  services. 

4.2.  I.2xx--Bearer  Services  Supported  by  an  ISDN.  (Revised  at  November  1983 
Meeting  of  Working  Teams  2,  3,  and  4  of  Study  Group  XVIII.) 

The  following  types  of  bearer  services  are  listed  in  the  current  draft  of 
1 .2xx. 


o  circuit  64  kbit/s  unrestricted  (transparent  hit  stream) 
o  circuit  64  kbit/s,  speech  information  transfer  (A  and  mu  law 
encoding) 

o  circuit  64  kbit/s,  voice  hand  (approximately  3.2  khz, 
unrestricted  as  to  content) 
o  384  kbit/s  leased-circuit 
o  1536  kbit/s  switched 
o  1920  khit/s  switched 
o  packet  mode  virtual  circuits 
o  connectionless  packet  service  on  a  D  channel 

4.3.  1.320 — Addressing  and  Numbering  Principles  in  ISDN.  (Revised  at 

November  1983  Meeting  of  Working  Teams  2,  3,  and  4  of  Study  Group  XVIII.) 

Three  fundamental  issues  have  plagued  the  development  of  an  ISDN  numbering 
plan.  First,  the  plan  needs  to  be  compatible  with  present  numbering  plans  so 
that  in  the  transition  period  to  the  fully  ISDN  era  existing  numbering  plans 
are  usable.  Second,  the  ISDN  plan  needs  to  be  able  to  accommodate  within  one 
plan  the  diverse  services  of  ISDNs.  Third,  some  feel  that  provision  needs  to 
be  made  for  addressing  and  specifying  private  and  dedicated  networks,  while 
others  do  not  want  to  cater  for  non-national  ISDN  networks. 

The  actual  IDSN  numbering  plan  will  be  specified  in  Recommendation  E.16n,  not 
yet  prepared,  which  is  the  responsibility  of  Study  Group  II.  (The  digit  n  has 
not  been  selected.)  Until  E.16n  is  available,  1.320  will  contain  more  details 
than  will  he  perhaps  in  the  final  version. 

The  structure  of  the  ISDN  address  in  the  present  draft  of  1.320  contains  four 
elements;  country  code,  trunk  code,  ISDN  subscriber  number,  and  ISDN 
sub-address.  These  are  further  grouped  as  follows. 

ISDN  address 

International  ISDN  number 
Country  code 
National  ISDN  number 

Trunk  code  and/or  destination  network 
identification 
ISDN  subscriber  number 
ISDN  sub-address 


The  country,  or  geographic  area,  codes  will  be  the  codes  presently  specified 
in  Recommendation  1.632.  Although  not  specified  by  1.320,  it  was  felt  that 
the  international  ISDN  number  need  not  be  longer  than  15  decimal  digits.  The 
maximum  lenght  of  the  subaddress,  which  is  optional,  is  specified  to  be  32 
decimal  digits. 

An  important  principle  stated  in  the  draft  recommendation  is  that  provision 
will  be  made  for  specifying  destination  and  transit  networks  (e.g.,  MCI)  when 
permitted  by  national  regulations  and  these  networks  will  be  considered  when 
the  connection  is  routed.  The  transit  network  would  not  be  identified  by  the 
ISDN  number,  however,  but  would  be  identified  by  other  elements  in  the 
signalling  message.  (An  example  of  an  implication  would  be  that  if  a  user 
specifies  a  particular  routing  network  in,  say  the  U.S.A.,  and  multiple 
gateways  are  available  from  the  user  to  the  U.S.A.,  the  national  gateway 
closest  to  an  MCI  interconnection  point  would  be  chosen.)  Another  significant 
principle  is  that  mobile  users  area  to  be  addresses  the  same  as  a  stationary 
users.  Direct  dialing  in  (DDI)  is  to  be  supported. 

4.4.  1.325— ISDN  Connection  Types.  (Revised  at  November  1983  Meeting  of 

Working  Teams  2,  3,  and  4  of  Study  Group  XVIII.)  (I.3xx  was  previous 
designation.) 

The  following  families  of  ISDN  connection  types  are  listed  in  draft  1.325. 
o  64  kbit/s,  circuit  switched,  transparent 
o  64  kbit/s,  circuit  switched,  non-transparent 
o  64  kbit/s,  permanent,  non-switched,  transparent 
o  64  kbit/s,  permanent,  non-switched,  non-transparent 
o  384  kbit/s,  permanent,  non-switched,  transparent 
o  384  kbit/s,  permanent,  non-switched,  non-transparent 
o  Packet-virtual  circuit,  switched,  transparent 
o  Packet— virtual  circuit,  permanent,  non-switched,  transparent 
o  Packet — connectionless,  established  via  a  D-channel 

An  ISDN  connection  is  effected  by  one  or  more  connection  elements,  arranged  in 
tandem,  parallel,  or  point-to-multipoint  so  that  the  overall  end-to-end 
connection  has  the  required  characteristics.  The  various  elements  can  be 
established  and  released  simultaneously  (called  a  sequential  configuration)  or 
may  be  established  and  released  separately  (called  an  add/remove 
configuration) . 

1.325  lists  11  possible  connection  element  attributes,  but  describes  the 
following  four  as  the  major  ones. 

o  Mode  of  connection  (circuit  switched;  packet  switched) 
o  Establishment  of  connection  at  level  1  (demand;  reserved; 
permanent) 

o  Throughput,  bit  rate  (bit  rate;  other  types,  to  be  defined) 
o  Transparency  (transparent;  non-transparent;  others) 
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4.5.  1.300— ISON  Network  Functional  Principles.  (Revised  at  November  1983 

Meeting  of  Working  Teams  2,  3,  and  4  of  Study  Group  XVIII.) 

The  stated  purpose  of  1.300  is  to  be  an  overview  and  introduction  of  the 
network  series  of  recommendations.  This  series  of  recommendations,  in 
general,  describes  the  principles  of  what  is  to  be  done  rather  than  technical 
details  of  how  it  is  to  be  done.  The  principles  discussed  are  often  ultimate 
objectives  rather  than  immediate  requirements. 

Recommendation  X.200,  developed  by  Study  Group  VII,  describes  modern  open 
system  network  architecture  from  the  CCITT  viewpoint.  Open  system  means, 
broadly,  that  connection  to  the  system  is  open  to  all  terminals.  -  achieve 
this  objective,  various  functions  needed  to  transport  data  betwe*  cwo  or  more 
users  are  grouped  into  related  categories,  called  layers.  The  1  rs  are 
numbered  from  1  to  7  and  are  structured  such  that  a  layer  relies  <i  the 
previous  lower  numbered  layer  to  supply  services  to  it  so  that  *  an  supply 
other  services  to  the  next  higher  numbered  layer.  The  following  a  a  is  a 
rearrangement  of  figure  4  in  draft  recommendation  1.300,  and  has  ,ed  the 
names  by  which  the  layers  are  commonly  known.  Since  nomenclature  used  by 
ISDN,  such  as  network,  may  not  correspond  exactly  to  X.200  definitions  at 
present.  Study  Groups  XI  and  XVIII  often  avoid  specifing  a  layer  by  its  name. 

Layer  7  (Application  Layer) 

Application  related  functions 
Layer  6  (Presentation  Layer) 

Encryption/decryption 
Compression/expansion 
Layer  5  (Session  Layer) 

Session  connection  establishment 
Session  connection  release 
Session  connection  synchronization 
Session  to  transport  connection  mapping 
Session  management 
Layer  4  (Transport  Layer) 

Layer  4  connection  multiplexing 
Layer  4  connection  establishment 
Layer  4  connection  release 
Error  detection/recovery 
Flow  control 
Segmenting/blocking 
Layer  3  (Network  Layer) 

Routing/relaying 
Network  connection  establishment 
Network  connecton  release 
Network  connection  multiplexing 
Congestion  control 
Addressing 

Layer  2  (Data  Link  Layer) 

Data  link  connection  establishment 
Data  link  connection  lease 
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Flow  control 
Error  control 
Sequence  control 
Framing/synchronization 
Layer  1  (Physical  Layer) 

Physical  layer  connection  activation 
Physical  layer  connection  de-activation 
Bit  transmission 
Channel  structure  multiplex 

Draft  1.300  proposes  that  the  end  to  end  connection  be  considered  to  be 
composed  of  a  series  of  connection  elements.  When  the  user  initiates  a 
service  request,  a  set  of  attributes,  such  as  throughput  and  maximum  delay 
allowed,  would  be  specified.  Based  on  the  attributes,  an  appropriate  overall 
connection  type  would  be  determined,  such  as  64  kbit/s  circuit  switched, 
transparent.  (Transparent  implies  that  no  compression  of  data  is  allowed.  64 
kbit/s  voice,  on  the  other  hand,  could  be  converted  to  32  kbit/s  voice  on 
route,  as  long  as  it  was  converted  back  to  64  kbits/  at  the  other  end.)  A 
listing  of  ISDN  connection  types  is  in  table  1  of  draft  Recommendation  1.325. 
Between  different  modes,  different  connection  elements  could  be  used,  as  long 
as  they  would  allow  overall  end-to-end  characteristics  as  specified.  For 
example,  a  384  kbit/s  element  could  be  used.  Draft  Recommendation  1.325 
contains  a  list  of  ISDN  connection  types  in  table  1  and  a  list  of  connection 
elements  in  figure  6. 

4.6.  1.310 — ISDN  Functional  Architecture  Model — Part  A:  Functional  Model. 

(Revised  at  November  1983  Meeting  of  Working  Teams  2,  3,  and  4  of  Study 
Group  XVIII.) 

The  stated  purpose  of  1.310,  part  A,  is  to  provide  a  functional  description  of 
ISDN  capabilities.  Part  B,  which  in  the  present  draft  is  referred  to  as 
containing  architectural  descriptions,  has  not  been  included.  In  previous 
drafts,  part  B  contained  conceptual  examples  of  connections  between  various 
ISDN,  specialized  (e.g.,  X.25),  and  private  networks  along  with  some 
politically  sensitive  diagrams  showing  interfaces  between  the  line 
terminations  at  the  central  office  switch  and  the  switch. 

Draft  1.310  introduces  the  concept  of  lower  layer  functions  (LLF)  and  higher 
layer  functions  (HLF),  where  the  lower  layers  are  layers  1,  2,  and  3  of  the 
open  system  model  while  the  higher  layers  are  layers  4,  5,  6,  and  7.  The 
lower  layer  functions  are  subdivided  into  bearer  functions  (BF)  and  additional 
lower  layer  functions  (ALLF).  Bearer  function  functions  are  the  basic 
functions  needed  to  transport  data  between  users,  while  ALLF  are  other  lower 
level  services,  not  explicitly  defined  at  this  time.  The  finalization  of 
definitions  of  BF,  ALLF,  and  HLF  has  been  delayed  because  the  implication  they 
may  have  on  economic  and  regulatory  factors,  such  as  the  prohibition  of  some 
telecommunication  providers  to  furnish  higher  layer  functions  in  a  regulated 
environment  (e.g.,  the  FCC  computer  inquiry  in  the  U.S.A. ).  Draft  1.310 
repeats  the  table  of  functions  in  each  architectural  layer  and  the  connection 
element  diagrams  from  1.300.  Draft  I.2xx  (see  §4.2)  discusses  bearer  service 
attributes. 


4.7  I. 377 — ISDN  Protoco7  Reference  ModeT.  (Revised  at  November  7983  Meeting 
of  Working  Teams  2,  3,  and  4  of  Study  Group  XVIII.) 

This  draft  recommendation  contains  many  two  and  three  dimensional  figures 
showing  how  the  various  architectural  layers  are  related  in  connections 
through  circuit  and  packet  switches  between  users.  The  figures  use  a  concept, 
not  yet  accepted  by  a77  open  system  architecture  experts,  of  separate  control 
and  user  planes  in  the  architectural  models.  That  is,  network  control, 
end-to-end,  may  flow  through  a 7 7  seven  7ayers  as  does  user  data.  (The 
aTternative  approach  is  to  consider  that  layer  three  in  the  connection 
containing  the  user  data  connects  functiona77y  with  other  appiication 
programs,  which  may  have  seven  Tayers,  at  the  network  nodes.) 

4.8.  Draft  I.437--Basic  User/Network  Interface  -  Layer  7  Specifications. 

(Revised  at  November  7983  Meeting  of  Working  Teams  2,  3,  and  4  of  Study 
Group  XVIII.) 

In  order  to  allow  development  of  ISDN  protocol  modules  that  have  well-defined 
inter-module  boundaries,  the  recommendations  follow  the  Open  System 
Interconnection  Reference  Model  layers.  Recommendation  1.437  has  Tayer  7 
specification  in  its  titie,  but  it  actuaiiy  contains  more  than  Tayer  7 
specifications.  Layer  7  of  the  Open  System  Interconnection  Reference  Model  is 
usually  considered  to  be  transmission  media  independent;  that  is,  it  does  not 
describe  the  media  physical  characteristics,  but  only  its  functional 
characteristics.  However,  draft  Recommendation  1.437  gives  detaiied 
specifications  for  the  e7ectrica7  characteristics  of  the  generators  and 
receivers,  in  addition  to  specifications  of  Tayer  T  functionaT  procedures. 
"Basic"  in  the  titie  refers  to  a  specific  type  of  interface;  nameiy,  the 
interface  that  has  two  B  channeTs  at  64  kbit/s  each  and  a  D  channeT  at  76 
kbit/s. 

Recommendation  1.437  can  be  broadTy  dividied  into  four  sections:  (7) 
configuration  of  distribution  wiring  at  the  user's  premises,  (2)  eiectricai 
characteristics  of  generators  and  receivers,  (3)  operating  power  requirements 
and  connections  for  ISDN  portion  of  terminals,  (4)  procedures  for  activating 
and  deactivating  the  digital  link,  and  (5)  format  of  the  frame  of  bits 
representing  the  B  and  D  channels.  Each  of  these  sections  wi77  be  summarized 
briefly  in  the  following  paragraphs. 

4.8.7  Two  wire  pairs  are  needed  to  connect  ISDN  terminals,  one  for 
transmitting  and  one  for  receiving.  Due  primarily  to  the  insistence  by  the 
European  members  of  CCITT,  the  ISDN  basic  interface  has  been  designed  to  allow 
connection  of  parallel  terminals  at  the  user's  premises,  much  as  parallel 
telephone  extensions  can  be  connected  in  the  present  analog  networks.  This  is 
called  a  passive  bus  arrangement  since  no  active  elements  are  between  the 
network  termination  and  terminals.  Because  the  ISDN  interface  is  digital  and 
operates  at  the  fairly  high  rate  of  792  kbit/s,  connection  of  paraTTei 
terminais  must  be  done  much  more  carefuTTy  than  is  required  for  existing 
teTephones.  Three  configurations  are  discussed  in  1.437.  In  a  point-to-point 
configuration  allowing  only  one  terminal  or  telephone  on  the  Tine,  as  might  be 


the  case  when  connected  to  a  PABX,  the  distance  of  the  connecting  wiring  can 
be  up  to  7000  meters.  When  up  to  8  termi. uTs  are  connected  in  parallel,  the 
total  length  of  the  connecting  bus  can  be  up  to  150  meters  and  the  lengths  of 
the  stubs  connecting  the  terminals  to  the  bus  should  not  exceed  10  meters.  In 
an  extended  bus  arrangement  in  which  distances  between  connection  of 
individual  terminals  is  limited  to  35  meters,  the  total  length  of  the  bus  can 
be  about  500  meters.  The  worst  possible  configuration,  insofar  as  reflections 
and  delays  are  concerned,  is  for  one  terminal  to  be  connected  near  the  network 
termination  and  the  rest  connected  in  a  cluster  at  the  other  end  of  the  bus. 

It  should  be  noticed  by  system  implemented  that  simple  active  elements  that 
repeat  the  digital  and  signal,  and,  perhaps,  adjust  timing  offset,  can 
eliminate  many  of  the  electrical  deficiencies  of  the  passive  bus  and  extend 
its  permitted  length.  While  an  active  bus  configuration  is  illustrated  in 
1.431,  no  specifications  concerning  it  are  given. 

4.8.2  Detailed  voltage  pulse  specifications  are  given  in  the  form  of  pulse 
shape  masks.  The  nominal  output  voltage  is  750  mv.  The  terminal  transmitter 
output  impedance  and  receiver  imput  impedance  are  functions  of  frequency,  but 
are  about  2,500  ohms  in  the  20  khz  to  80  khz  range. 

Electromagnetic  interference  radiation  from  ISDN  wiring  is  apt  to  be  fairly 
significant  unless  the  system  is  carefully  balanced  around  ground  and  the 
voltages  are  kept  low.  It  has  been  agreed  that  shielded  wiring  should  not  be 
necessary,  but  in  special  situations  it  should  be  considered.  The  standard 
ISDN  connector  for  the  basic  interface  will  be  the  eight-circuit  modular  plug 
now  used  on  A.T.ST.  equipment. 

4.8.3  There  will  probably  be  more  than  one  way  of  supplying  power  to  ISDN 
terminals  since  terminal  types  will  vary  from  digital  telephones  to  large 
computers.  Because  of  difficulty  in  transmitting  power  over  optical  fibers 
from  central  offices  and  because  of  the  desire  to  simplify  the  network 
termination  at  the  user's  premises,  it  is  possible  that  central  office  power 
will  not  be  supplied  to  terminals,  even  digital  telephones,  in  the  U.S.  There 
are  two  specified  ways  of  supplying  power  to  terminals,  over  a  phantom 
arrangement  of  the  transmitting  and  receiving  circuits  and  over  two  separate 
connectors.  The  power  on  the  phantom  may  be  from  the  network  or  from  a  power 
supply  connected  to  the  local  a.c.  source.  The  amount  of  this  power  in  normal 
operating  conditions  is  not  specified  in  ISDN  recommendations.  Under 
emergency  situations,  as  when  the  local  a.c.  source  fails,  the  power  on  the 
phantom  will  be  at  least  400  mW,  if  supplied,  and  will  be  reversed  in  polarity 
to  indicate  that  a  limited  power  condition  exists.  The  d.c.  voltage  of  the 
supply  will  be  either  24  volts  or  40  volts.  When  a  terminal  is  powered  down 
(that  is,  inactive)  it  must  not  consume  more  than  X  watts,  where  X  will 
probably  be  between  0  and  50  mW. 

4.8.4  Proper  activation  and  deactivation  of  a  terminal  as  it  is  powered  up  or 
down  or  connected  or  disconnected  from  a  bus  is  rather  complicated  because  it 
must  not  disturb  any  other  terminal  that  might  be  active.  Additionally,  it 
must  ultimately  synchronize  to  a  framing  sequence  that  accommodates  the  two  B 
channels,  the  D  channel,  and  spare  bits.  Basically,  a  terminal  when  first 


connected  listens  to  the  receiving  side  of  the  bus.  Three  signals  are 
possible:  no  signal  (called  INFO  0),  alternating  positive  and  negative  pulses 
(called  INFO  2)  and  normal  operational  data  (called  INFO  4).  In  general,  INFO 
2  indicates  that  an  attempt  is  being  made  by  the  network  termination  to 
activate  the  bus.  If  the  terminal  deduces  from  INFO  0  that  the  bus  is  active, 
it  transmits  framing  pulses  but  sets  all  data  bits  to  logical  1  (zero  voltage 
level)  to  indicate  that  it  would  like  for  the  bus  to  be  activated. 

4.8.5  The  proposed  frame  structure  for  the  basic  ISDN  access  interface  has  48 
bits  and  is  transmitted  in  250  microseconds,  which  equates  to  a  bit  rate  of 
192  kbit/s.  The  technique  is  called  pseudo  ternary,  which  means,  here,  that 
logical  Is  are  transmitted  as  zero  volts  and  logical  Os  are  transmitted  as 
alternating  positive  and  negative  pulses  of  about  .75  volts  amplitude. 

Framing  boundaries  are  indicated  by  points  at  which  the  alternating  positive 
and  negative  pulse  rule  is  violated.  That  is,  framing  pulses  are  logical  Os 
that  are  transmitted  with  the  same  polarity  as  the  preceding  logical  0;  the 
preceding  logical  0  may  not  occur  in  the  preceding  bit  position,  so  the 
framing  mechnism  must  remember  the  polarity  of  each  logical  0  until  the  next 
is  received.  Each  group  of  bits  that  might  be  transmitted  from  one  terminal, 
such  as  eight  B  channel  bits,  is  followed  by  a  balancing  bit,  called  an  L  bit, 
that  insures  that  the  d.c.  balance  is  restored  to  the  bus.  Since  logical  Os 
are  alternating  pulses,  there  can  never  be  more  than  one  bit  out  of  balance 
before  the  L  bit. 

Contention  resolution  between  two  or  more  terminals  trying  to  access  the  bus 
at  once  is  reconciled  at  two  levels.  At  the  higher  level,  a  terminal  does  not 
transmit  on  either  of  the  B  (64  kbit/s)  channels  without  receiving  permission 
to  do  so  on  the  D  (16  kbit/s)  channel.  At  the  lower  level,  contention  on  the 
D  channel  is  resolved  electrically.  Each  D  channel  bit  from  terminals  to  the 
network  termination  (NT)  is  echoed  by  by  the  NT  as  an  E  bit.  As  seen  by  the 
NT,  the  D  channel  bits  are  controlled  by  the  terminals  attempting  to  raise  the 
D  bit  from  the  zero  voltage  level.  For  example,  if  two  terminals  a 
transmitting  a  D  bit  simultaneously  and  one  transmits  a  zero  voltage  (1  bit) 
while  the  other  transmits  a  positive  voltage  (0  bit),  the  NT  would  see  a 
positive  voltage  and  echo  a  0  bit.  The  convention  is  that  a  terminal  that 
sees  a  E  bit  that  is  not  the  same  as  the  corresponsing  D  bit  it  transmitted 
should  cease  transmission,  thereby  resolving  the  contention. 

4.9.  Draft  1.432— Primary  Rate  User/Network  Interface  -  Layer  1 

Specifications.  (Revised  at  November  1983  Meeting  of  Working  Teams  2, 

3,  and  4  of  Study  Group  XVIII.) 

The  primary  rate  ISON  interface  will  operate  at  1544  kbit/s  or  at  2048  kbit/s 
to  conform  with  existing  digital  transmission  equipment,  the  lower  rate  being 
used  primarily  in  the  U.S.A.  One  use  of  the  primary  rate  interface  might  be 
to  connect  PABXs  to  ISDNs.  The  interface  will  accommodate  23  B  channels  and  a 
D  channel  at  the  lower  rate  or  30  B  channels  and  a  D  channel  at  the  higher 
rate.  Alternately,  groups  of  six  B  channels  can  be  replaced  by  Hq  channels 
operating  at  384  kbit/s.  For  the  1544  kbit/s  interface,  all  B  channels  and 
the  D  channel  can  be  replaced  by  an  H-j  channel  operating  at  1536  kbit/s;  for 
the  2048  kbit/s  interface,  all  B  channels  can  be  replaced  by  an  H]  channel 
operating  at  1920  kbit/s. 


The  basic  electrical  characteristics  of  the  interfaces  are  specified  in 
Recommendation  G.703  which  recommends  electrical  characteristics,  bit  rates, 
pulse  shape,  impedance,  and  code.  Section  2  applies  to  the  1544  kbit/s 
interface  while  section  6  corresponds  to  the  2048  kbit/s  interface.  The  D 
channel  of  the  primary  rate  interface  operates  at  64  kbit/s  instead  of  the  16 
kbit/s  rate  of  the  basic  rate  interface.  The  protocol  of  the  D  channel  can  be 
either  that  defined  in  ISDN  Recommendation  Q.930  or  it  can  be  that  of  the 
Signalling  System  Number  7  protocol  in  Recommendations  Q.701  through  Q.741,  in 
which  case  it  is  referred  to  as  an  E  channel. 

4.10.  Draft  Recommendation  Q.920  (I.441)--Specification  of  the  ISDN 

User-Network  Interface  Data  Link  Layer  Protocol.  (Issue  6,  November 
1983.) 

This  recommendation  specifies  a  data  link  layer  protocol  that  will  be  used  on 
the  out-of-band  signalling  channel,  called  the  D  channel,  in  IDSN  networks 
between  the  user  terminals  and  the  network.  The  data  link  layer  protocol  in 
Q.920  is  basically  the  protocol  described  as  LAPB  in  Recommendation  X.25  and 
as  Asychronous  Balanced  mode  of  operation  in  International  Standard  IS-4335, 
published  by  the  International  Organization  for  Standardization,  and  in 
American  National  Standard  X3.66,  published  by  the  American  National  Standards 
Institute.  There  is  a  fundamental  difference,  however,  in  that  Q.920  has 
incorporated  an  address  field  that  permits  the  NT  (network  termination)  to 
communicate  with  several  terminals  connected  in  parallel  whereas  the  other 
three  standards  restrict  the  balanced  mode  to  operate  between  two  points 
only.  Q.920  uses  a  two-octet  address  field  according  to  the  standard 
extension  rules  of  IS-4335  and  ANS  X3.66,  but  not  incorporated  in  LAPB.  Q.920 
also  has  the  UI  (Unnumbered  Information)  frame,  which  is  not  included  in 
LAPB.  In  addition,  Q.920  contains,  for  clarification,  much  descriptive 
material  on  states  assumed  by  the  data  link  layer  protocol  processors  and  on 
primitives  passed  to  and  from  the  data  link  layer  and  other  protocol  layers. 

Another  fundamental  difference  is  that  Q.920  describes  also  a  Single  Frame 
Operation  which  makes  use  of  a  new  frame,  not  yet  considered  or  approved  by 
other  standards  organziations.  This  new  frame  is  called  a  TBN  (To  Be  Named) 
frame  and  functions  much  as  a  UI  frame  would  if  the  P/F  (poll/final)  bit  in 
the  UI  frame  is  replaced  by  a  modulo  2  sequence  counter.  (See  §5.5  in 
Q.920.)  No  other  commands  or  responses  are  used  in  the  Single  Frame  Operation 
mode. 

The  certainty  of  the  future  continuing  specification  of  the  TBN  frame  will  be 
determined  after  more  thorough  analysis  of  its  operation,  both  in  CCITT  and  in 
other  standards  organizations.  It  was  introduced  in  order  to  have  a  simple 
protocol  in  which  the  NT  and  a  terminal  could  exchange  frames  alternately. 
Possible  other  ways  of  doing  the  same  thing  are  limiting  the  number  of 
outstanding  I  (information)  frames  to  one  or  using  a  standard  UI  frame 
exchange  and  tolerating  the  occasional  loss  of  a  frame. 

The  other  major  difference  between  Q.920  and  similar  data  link  layer  standards 
is  that  Q.920  describes  in  detail  how  the  contents  of  the  address  field  is 
determined,  using  layer  3  messages.  (See  §1.3. 4. 3,  §3.2,  §3.3,  and  §5.3  in 
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Q.920. )  This  is  necessary  in  ISDN  systems  because  several  terminals  may  be 
connected  in  parallel  and  can  be  moved  by  the  user  to  other  locations.  The 
central  office  needs  to  have  some  way  of  identifying,  at  layer  2,  a  particular 
terminal  so  that  it  can  send  messages  to  it  and  not  to  all  terminals  in 
parallel.  The  way  this  is  done  in  ISDN  is  for  the  terminal  to  request  from 
the  switch  that  a  particular  TEI  (terminal  endpoint  identifier)  be  assigned  to 
it.  The  procedure  then  checks  to  see  if  the  same  TEI  is  being  used  by  another 
terminal  connected  to  the  same  parallel  bus.  If  it  is,  another  TEI  must  be 
selected.  Provision  is  also  made  for  terminals  that  have  a  particular  set 
TEI,  as,  for  example,  a  TEI  incorporated  in  the  protocol  integrated  circuit 
chip.  These  terminals,  however,  may  lack  the  flexibility  of  movement  of  those 
with  an  automatic  TEI  assignment. 

The  complete  data  link  layer  address  consists  of  TEI  and  a  SAPI  (service 
access  point  identifier).  Usually,  a  terminal  has  only  one  TEI,  but  may  have 
several  SAPIs  to  identify  several  processes  within  the  terminal,  each  of 
which,  in  theory,  could  operate  over  a  separate  connection  within  the  ISDN. 

The  SAPIs  can  be  assigned  independently  by  the  terminal,  since  the  TEI  portion 
of  the  address  will  be  unique  to  that  terminal. 

Q.920  assigns  bits  3  through  8  of  the  first  octet  of  the  data  link  layer 
address  field  to  the  SAPI  and  bits  2  through  8  of  the  second  octet  to  the 
TEI.  Of  the  64  possible  SAPIs,  value  0  is  specified  for  circuit-switched 
procedures,  value  16  for  packet-switched  procedures,  and  value  63  for  network 
management  procedures.  The  127  possible  TEI  values  are  divided  into  three 
groups,  values  0  through  63  for  non-automatic  TEI  assignment  equipment,  values 
64  through  126  for  automatiac  assignment  user  equipment,  and  value  127  for  the 
group  address  (all  stations). 

4.11.  Draft  Recommendation  Q.930  ( I.451)--Specif ication  of  the  ISDN 

User-Network  Interface  Layer  3  Protocol.  (Revised  at  November  1983 
Meeting  of  Working  Party  XI/6.) 

The  information  fields  of  the  frames  specified  in  Q.920  contain  two  general 
types  of  messages,  specified  by  Q.930.  The  first  type  are  messages  that 
directly  control  the  establishment  of  connections  for  the  B  (64  kbit/s) 
channels.  This  type  is  similar  in  function,  then,  to  the  on-hook,  off-hook, 
and  dial  pulse  signals  sent  from  a  standard  analog  telephone.  The  other  type 
are  messages  that  may  contain  user  data  and  may  be  switched  by  packet  handling 
facilities  within  the  ISDN.  (According  to  present  draft  recommendations, 
packet  handling  facilities  outside  the  ISDN  must  be  connected  through  the  B 
channel.)  To  distinguish  between  the  types  of  messages,  the  first  octet  in 
the  information  field  contains  a  protocol  discriminator,  which,  when  set  to 
value  8,  indicates  that  the  message  is  a  Q.930  user-to-network  call  control 
message.  Use  of  other  values  is  reserved  for  future  standardization,  with 
values  16  through  63  and  80  through  1022  designated  as  "reserved  for  other 
network  layer  protocols,  including  X.25." 

There  are  two  categories  of  user-to-network  call  control  procedures,  called 
functional  signalling  and  stimulus  signalling.  Functional  signalling  is 
usually  the  most  efficient  mode  of  signalling  if  the  terminal  has  some 


Intelligence,  but  requires  that  the  terminal  remember  which  of  the  20 
presently  defined  states  it  is  in  and  generate  and  interpret  sometimes 
relatively  complex  messages  as  it  interacts  with  the  network.  Stimulus 
signalling,  on  the  other  hand,  requires  that  the  terminal  remember  only  two 
states  (on-hook  or  off-hook,  and  receiving  an  alerting  signal  or  not),  but  may 
lack  flexibility  in  simultaneous  use  of  more  than  one  B  channel.  Stimulus 
signalling  procedures  are  designed  so  that  an  operator  can  supply  the  logic  to 
establish  and  disconnect  calls,  similar  to  operation  of  the  analog  telephone 
today.  Functional  signalling  procedures  take  advantage  of  the  intelligence  of 
processors  to  perform  these  steps  automatically.  Of  course,  a  processor  could 
be  programmed  to  automatically  perform  the  steps  in  a  stimulus  signalling 
procedure  as  if  it  were  the  operator. 

As  an  example  of  the  difference  in  the  functional  signalling,  the  call  set-up 
message  sent  when  a  stimulus  terminal  goes  off-hook  would  usually  contain 
only  a  call  reference  (a  number  that  identifies  a  particular  call  to  both  the 
terminal  and  network),  an  indication  of  what  type  of  call  is  being  initiated 
(such  as  a  64  kbit/s  encoded  voice  call),  and,  optionally  an  indication  hat 
the  terminal  is  off-hook.  The  dial  signals  would  be  sent  in  subsequent 
messages,  either  one  at  a  time  (overlap  sending)  or  all  together  (en  bloc)  if 
the  terminal  could  store  the  numbers  until  all  were  keyed  in.  The  call  set-up 
message  from  a  function  terminal  would  usually  contain  those  sent  by  a 
stlmumus  terminal  plus  the  called  number  and  additional  elements  to  indicate 
other  desired  features,  such  as  remote  charging  and  request  for  cost  of  call 
after  completion. 

The  stimulus  signalling  procedures  have  been  introduced  in  CCITT  recently, 
supported  primarily  by  A.T.&T.  and  its  derivative  companies.  There  is 
considerable  debate  within  CCITT  as  to  whether  these  simplified  procedures 
will  allow  manufacturer  of  a  cheaper  terminal  in  the  long  run.  The  fact  that 
stimulus  signalling  procedures  may  not  be  standardized  worldwide  and  that 
certain  switches  may  support  only  either  stimulus  or  functional  signalling 
could  affect  a  manufacturer's  ability  to  have  only  one  worldwide  product  line 
and  a  user's  ability  to  move  terminals  between  geographic  locations.  A 
stimulus  terminal  should  be  more  easily  adapable  to  new  operational  features, 
however,  since  the  programming  change  would  be  in  the  operator's  mind  rather 
than  in  the  equipment  firmware.  (For  a  discussion  of  the  economic 
Implications  of  stimulus  and  functional  signalling  and  how  they  might  impact 
profits  of  network  operators  and  terminal  manufacturers,  see  the  "Future 
Phone"  article  on  the  front  page  of  The  Wall  Street  Journal,  December  23,  1983.) 


5.  SOME  COMMONLY  USED  ISDN  TERMS. 


the  basic  functions  performed  by  the  network  in  providing  a  connection, 
but  still  not  related  to  the  higher  (e.g.,  5,  6,  7)  layers  of  the 
architectural  model. 


Alpha  service- 

used  to  describe  network  services  lying  between  the  basic  connection 
service  (bearer  service)  and  telecommunications  services  that  provide 
additional  features,  such  as  terminal  compatibility  checking;  term  may  not 
be  used  in  the  future. 

B  channel— 

a  switchable,  optionally  transparent,  64  kbit/s  channel;  two  such  channels 
are  included  in  the  basic  access  service. 

Basic  rate — 

an  ISDN  access  rate  of  192  kbit/s  (2  B  channels  and  a  D  channel) 

Bearer  service- 

basic  connection  service,  with  out  of  band  signalling  (e.g.,  signalling  on 
the  D  channel) . 

C  channel— 

a  channel  operating  at  2,  4,  8,  or  16  kbit/s  and  associated  with  analog 
voice  transmission,  rather  than  with  B  channels;  this  channel  performs 
some  of  the  functions  of  a  D  channel;  not  presently  being  pushed  in  CCITT. 


CN- 

connection. 


Compelled— 

a  mode  of  operation  at  layer  2  (link  layer)  that  uses  non-sequenced 
information  frames  with  only  one  unacknowledged  frame  allowed  to  be 
outstanding;  acknowledgement  effected  through  poll  and  final  bit 
exchanges;  similar  in  operation  to  "ACK-NAC"  protocols,  except  "NAC"  is 
implicit  rather  than  explicit;  also  referred  to  as  "simplified  protocol". 


CRF — 

connection-related  functions. 


CT— 

connection  type;  basic  characteristic  of  a  connection;  e.g.,  64  kbit/s, 
circuit  switched,  transparent;  described  in  Recommendation  1.325. 


Connection  element— 

a  component  of  a  connection  type. 


D  channel— 

a  channel  whose  primary  purpose  is  to  convey  signalling  information 
between  a  terminal  and  the  network  switch,  but  whose  surplus  capacity  can 
be  used  for  user  packet  data  and  other  data,  such  as  telemetry;  it 
operates  at  16  kbit/s  for  basic  access  and  at  64  kbit/s  for  primary  access 
rates. 


DSL- 

digital  subscriber  loop. 

E  bit- 

bit  that  echoes,  in  the  network  to  terminal  (NT  to  TE)  direction,  D 
channel  bit  in  the  TE  to  NT  direction;  used  in  contention  resolution 
procedures  when  more  than  one  terminal  attempts  to  use  the  D  channel  at 
the  same  time.  (Notice  that  the  E  bits  are  not  the  bits  used  by  the  E 
channel.) 

E  channel— 

a  channel  operating  at  64  kbit/s  and  using  CCITT  signalling  system  number 
7  protocols;  it  may  supplement  or  be  used  in  place  of  a  D  channel  for 
connections  of  private  branch  exchanges.  (The  E  channel  will  likely  use  D 
channel  bit  positions  or,  perhaps,  other  yet  to  be  defined  bit  positions.) 


EMI- 

electromagnetic  interference;  refers  to  possible  radiation  from  leads 
connecting  ISDN  equipment. 

ET— 

exchange  termination;  the  termination  at  the  central  office  immediately 
before  the  switching  stages;  connects  to  V  reference  point  on  the  customer 
side. 

F  bit- 

framing  bit  in  the  access  frame  structure 
FA  bit- 

auxiliary  framing  bit;  used  to  ensure  proper  framing  if  no  user  data  is 
present  or  if  polarity  of  connecting  leads  is  reversed;  FA/S  indicates 
that  bit  can  be  used  as  spare  bit  in  some  frames. 


FF- 


fixed  format;  refers  to  a  fixed  structure  for  inserting  lower  bit  rates 
into  a  higher  bit  rate  channel  (rate  adapting);  contrasts  to  VF. 


HO  channel— 

a  channel  operating  at  384  kbit/s;  presently  specified  for  leased  circuits 
only;  can  be  used  for  high  fidelity  music. 

HI  channel — 

a  channel  at  a  higher  rate  than  HO;  1536  kbit/s  and  1920  kbit/s  are  under 
consideration. 

HLF — 

higher  layer  functions;  refers  to  services  performing  functions  related  to 
the  "higher"  layers  (e.g.,  5,  6,  7)  in  the  architectural  models;  examples 
might  be  data  base  related  functions. 
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HRX — 

hypothetical  reference  connection;  a  model  of  worst  case  connections  that 
is  used  to  study  the  various  technical  and  operational  aspects  of  the 
ISDN;  connection  may  not  he  actual  worst  case,  but  may  represent  typical 
worst  case. 

ISDN- 

Integrated  Services  Digital  Networks;  characterized  by  supporting  both 
voice  (digitized)  and  data  transmission. 

L  bit — 

dc  balancing  bit  in  the  frame  structure;  needed  because  coupling 
transformers  cannot  pass  dc. 

IT— 

line  termination,  at  the  switch  end  of  the  subscriber  connection. 


network  termination  type  2;  private  branch  exchanges  and  local  area 
network  controllers  are  examples  of  NT2s. 

PA- 

minimum  power  available  to  terminal  when  power  is  fed  by  phantom 
arrangement  over  signalling  leads  and  power  from  local  ac  source  is  not 
available;  present  draft  suggests  that  it  should  be  400  mW,  but  may  be 
reduced  to  250  mW  in  the  next  study  period;  this  may  be  only  power  in  case 
of  emergency  conditions.  Also  called  P  alpha. 

PB~ 

maximum  power  extracted  by  the  terminal  in  emergency  or  local  ac  power 
loss  situations  from  the  phantom  arrangement  over  the  signalling  leads; 
current  draft  does  not  use  Pg  but  indicates  a  maximum  available  current 
will  be  specified.  Also  called  P  beta. 

PG- 

minimum  power  available  to  terminal  when  power  is  fed  by  phantom 
arrangement  over  signalling  leads  and  power  from  local  ac  source  is 
available;  present  draft  says  that  its  value  will  be  up  to  individual 
administrations  (operating  companies). 

?N 

maximum  power  extracted  by  the  terminal  in  normal  operation  when  power  is 
fed  by  phantom  arrangement  over  signalling  leads;  not  used  in  current 
draft. 

PABX — 

private  automatic  branch  exchange. 

PH— 

packet  handling;  usually  used  to  refer  to  such  a  service  in  an  ISDN. 


Primary  rate — 

an  ISON  access  rate  of  either  7544  kbit/s  (23  B  channels  and  a  D  channel) 
or  2048  kbit/s  (30  B  channels  and  a  D  channel). 

S  Information — 

signalling  information;  used  with  S-plane  information  in  discussing 
architectural  model. 

S  bit — 

space  bit  in  the  frame  structure;  may  be  used  in  the  furure  for 
activation-deactivation  procedures  and  maintenance. 

S  interface — 

a  reference  point  on  the  customer  side  of  NT2;  as  an  example,  the 
interface  to  which  a  digital  telephone  could  connect  to  a  private  branch 
exchange. 

T  interface — 

a  reference  point  on  the  customer  side  of  NT1;  as  an  example,  the 
interface  to  which  a  digital  telephone  could  connect  (for  192  kbit/s 
interface)  or  to  which  a  local  area  network  gateway  controller  could 
connect;  the  bit  rate  may  be  either  192  kbit/s  for  basic  access  or  1544  or 
2048  kbit/s  for  primary  access. 

TE1 — 

terminal  equipment  type  1;  standard  ISDN  terminal  that  can  be  connected  to 
the  S  or  T  (192  kbit/s)  interface. 

TEI — 

terminal  endpoint  identifier;  a  link  level  identifier  (number)  that  is 
necessary  for  the  terminal  to  communicate  over  the  D  channel  with  the 
switch  or  NT;  this  may  be  variable  or  fixed  (see  page  A. 025). 

Teleservice— 

a  telecommunications  service  that  includes  functions  above  the  basic 
connection  service;  an  example  might  be  Telex. 

TR— 

termination  resistance;  a  resistance  used  to  prevent  electrical 
reflections  on  ISDN  connections;  specified  value  is  100  ohms,  t  5  per 
cent. 

Type  A— 

a  service  access  point  that  supports  a  layer  2  (link  layer)  protocol  that 
is  simpler  than  the  full  ISDN  protocol.  Type  B;  current  position  is  that 
all  switches  should  support  both  Type  A  and  Type  B,  but  simplier  terminals 
may  use  only  Type  A. 

Type  B— 

a  service  access  point  that  supports  the  full  ISDN  layer  2  (link  layer) 
protocol;  see  also  Type  A. 


Type  C — 

a  service  access  point  that  has  multiple  layer  2  links,  for  redundancy  and 
reliability;  not  expected  to  be  included  in  recommendations  of  this  study 
period  (1981-1984),  but  will  be  studied  in  the  next  study  period. 

U  Information- 

user  information;  used  with  U-plane  information  in  discussing 
architectural  model. 

U— 

a  reference  point  at  each  end  of  the  connection  between  the  subscriber  and 
the  local  switch;  NT1  connects  to  U  at  the  subscriber  end  and  LT  connects 
at  the  switch  end;  characteristics  unlikely  to  be  standardized  by  CCITT. 

VF~ 

variable  format;  refers  to  a  variable  structure  for  inserting  lower  bit 
rates  into  a  higher  bit  rate  channel  (rate  adapting);  contrasts  to  FF  (see 
page  A. 01 1) . 

V— 

a  reference  point  between  the  LT  and  ET. 
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A. 097  3.  Modes  of  Operation 

4.  Types  of  Wiring  configuration 
A. 098  5.  Functional  characteristics 

A. 104  6.  D-channel  access  control 

A. 113  7.  Layer  1  Maintenance 

A. 114  8.  Electrical  characteristics 

A. 125  9.  Power  Feeding 

A. 127  Appendix  1  -  Elements  for  layer  to  layer  communications 
1.  General 

A. 128  Annex  1  -  (to  Recomm  1.431)  -  Wiring  configurations  and 

interconnecting  media  characteristics  used  as  a  basis  for  electrical 
characteristics 

1.  Introduction 

2.  Wiring  configurations 

A. 129  3.  Interconnecting  media  characteristics 

A. 131  Annex  2  -  (to  draft  Recomm  1.431)  -  Jitter  and  bit  phase  relationship 
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A. 138  Report  of  the  Ad  Hoc  Group  on  Recommendation  1.432 

1.  General 

2.  Documents 

3.  Discussion  of  draft  Recommendation  1.432 

A. 139  Draft  Recommendation  1.432  -  Primary  Rate  User/Network  Interface  -  Layer  I 
Specification 

1.  Introduction 

2.  Types  of  configuration 

A. 140  3.  Functional  characteristics 

A. 141  4.  Interface  at  1544  kbit/s 

A.  143  5.  Interface  at  2048  kbit/s 

A. 145  6.  Mechanical 
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2.  Frame  structure  for  peer-to-peer  communications 

3.  Elements  of  procedure  and  format  of  fields  for  data  link  layer 
peer-to-peer  communications 

4.  Elements  for  layer-to- layer  communication 

5.  Definition  of  the  peer-to-peer  procedures  of  the  data  link  layer 
Appendix 

Draft  Recommendation  Q.930  (1.451)  -  Specification  of  the  ISDN 
User-Network  Interface  Layer  3  Protocol 

1.  General 

2.  Overview  of  call  control 

3.  Message  functional  definitions 

4.  Message  structure 

5.  Call  control  procedures 

6.  Application  of  circuit-switched  call  control  procedures  to 
terminals  operating  in  a  stimulus  mode 
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Question  I/XVIII,  p.A 
SOURCE:  WORKING  TEAM  4 

TITLE:  ANNEX  2  TO  THE  REPORT  OF  WORKING  TEAM  4  -  DRAFT  RECOMMENDATION  1.200  - 

SERVICES  SUPPORTED  RY  AN  ISDN 


Considering 

the  ISDN  concept  described  in  Recommendation  I. 120; 

the  ISDN  functional  architecture  model  described  in  draft 
Recommendation  1.310;  not  available  this  study  period.  1.300  give  principles. 

the  ISDN  protocol  reference  model  described  in  draft  Recommendation 

1.311; 

the  ISDN  connection  types  described  in  draft  Recommendation  1.325; 

=  the  ISDN  user  network  interface  reference  configurations  described  in 
draft  Recommendation  1.411; 

the  ISDN  service  characterization  described  in  draft  Recommendations 
I.2xx  and  I.2xy;  (Does  not  exist  at  present.) 

and  ISDN  will  support  a  wide  variety  of  services.  The  purpose  of  this 
Recommendation  is  to  provide  a  clarification  and  a  method  of  description  of  such 
services  to  be  used  as  a  basis  for  defining  the  network  capabilities  required  by 
ISDN. 

1 .  Service  concept 

In  the  context  of  this  Recommendation  a  service  is  a  set  of 
capabilities  for  communication  which  is  defined  by  standardized  protocols  and 
functions. 

Realization  of  the  capability  for  communication  according  to  a  service 
requires  a  combination  of  network  and  terminal  functions.  The  service 
classification  and  descriptions  in  the  following  are  independent  of  different 
possibilities  for  ownership  and  form  of  provision  (to  the  customer)  of  the  means 
required  to  support  a  service. 

A  service  provision  by  the  network  provider  to  a  customer  connected  to 
an  ISDN  may  cover  the  whole  or  only  part  of  the  means  required  to  fully  support 
the  service.  The  operational  and  commercial  features  associated  with  the 
service  provision  are  included  in  the  service  concept. 

In  the  following,  services  are  described  by  attributes  that  define 
service  characteristics  as  they  apply  at  a  given  reference  point,  e.g.  S/T  for 
hearer  services,  see  section  3. 


A  supplementary  service  is  used  to  modify  or  supplement  a  service. 

It  cannot  be  offered  to  a  subscriber  as  a  stand  alone  entity.  It  must  be 
offered  together  with  or  in  association  with  main  services.  The  same 
supplementary  attributes;  the  supplementary  low  layer  and  high  layer 
attributes.  The  concept  of  ISDN  supplementary  service  corresponds  to  the 
concept  of  user  facility  in  the  X-series  of  Recommendations. 

The  concept  of  service  classification  is  illustrated  in  Table  1/1.200 


TABLE  1/1.200 

Telecommunication  service  classification 


Telecommunication  Service 


Bearer  Service 

I 

Basic _ 

Supplementary 

Teleservice 

Basic 

Supplementary 

2.  Elements  to  support  a  service 

2.1  The  elements  required  to  fully  support  a  service  for  a  customer 
connected  to  an  ISDN  include: 

network  functions 

possibly  terminal  functions 

operational  and  commercial  (i.e.  sales  or  marketing  aspect.,)  features 
associated  with  the  service  provision. 


Network  functions  are  specified  by  Recommendation  1.3... . 


2.2  To  support  services  an  ISDN  depending  on  national  regulations, 
provides  the  following  network  functions  whose  definition  appears  in 
Recommendation  I. 310: 

1.300  -  Principles 
1.325  -  Connection  Types 

-  Connections  with  the  Basic  Low  Layer  Functions  (BLLF)  and  optional 
Additional  Low  Layer  Functions  (ALLF). 

Depending  on  the  category  of  service  (see  para  3)  it  may  also 
provide,  when  permitted. 


-  Sasic  High  Layer  functions  (BHLF)  and  optional. 

-  Additional  High  Layer  Functions  (AHLF). 


Connections 


Note  -  In  certain  national  situations  some  type  of  sophisticated  bearer 
services  could  also  be  provided  by  cooperation  of  an  ISDN  and  a  specialized 
network.  In  such  cases,  corresponding  ALLF  could  be  implemented  outside  this 
ISDN. 

FIGURE  1/1.200 
ISDN  network  functions 

2.3  An  ISDN  will  provide  a  limited  set  of  connection  types  to  be  used  for 
a  multiplicity  of  services.  A  service  may  be  supported  by  any  type 
of  connection,  the  BLLF  of  which  meets  the  requirements  of  the  basic 
low  layer  attributes  of  this  service. 

2.4  Basic  high  layer  functions  (BHLF)  and  additional  high  layer  functions 
(AHLF)  may  be  implemented  in  specialized  centres,  in  modes  of  dedicated 
networks  as  well  as  integrated  in  ISDN  equipments.  Whatever  the 
implementation,  user-network  and  user-user  protocols  specified  for  the  service 
should  consider  functional  entities  corresponding  to  high  layer  functions  as 
completely  separate  from  those  corresponding  to  connections  or  additional  low 
layer  functions. 

Note:  Definitions  of  Low  Layer  Function  and  High  Layer  Function  will  he 
attached  as  an  Appendix. 
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Note  -  Dependent  upon  national  regulations,  HLF  may  be  provided  by 
administrations,  RPOAs  or  other  supplies. 

2.5  The  following  customer  entitites  may  be  connected  at  the  reference 
points  S/T  (as  defined  by  Recommendation  1.411)  : 

-  customer  terminals; 

customer  systems,  e.g.  PABX,  LAN; 
private  networks. 

All  customer  entities  connected  to  ISDN  interfaces  at  the  S/T 
reference  points  must  meet  the  specifications  of  the  protocols  at  that 
interface  of  all  the  layers  that  are  included  in  the  definition  of  the  service 
used. 

For  some  services  the  service  definition  also  covers  some  terminal 
functions  and  characteristics  in  addition  to  those  specified  by  the  protocols 
at  the  interface. 

Note  1  -  Customer  terminals  and  systems  may  be  private  or  provided  by 
administrations,  RPOAs. 

Note  2  -  Some  of  the  ALLF  identified  for  ISDN  might  also  be  implemented  in 
certain  categories  of  terminals. 

2.5  The  operational  service  features  associated  with  a  service  offering 
may  include  features  for  maintenance,  charging,  user  control  of  service 
features,  etc.  The  operation  of  such  features  may  involve  terminal-network 
communication  and  may  therefore  be  viewed  as  applications  in  their  own  right. 

Their  specification  could  imply  the  seven  layers  of  OS I  model  as  well  as 
procedural  aspects  that  are  beyond  the  OSI  context. 

Information  flows  used  to  control  or  manage  ISDN  services  may  involve 
protocols  modelled  by  layers  higher  than  OSI  layers  1-3  (see  draft 
Recomnendation  1.311),  and  is  independent  of  the  terms  High  Layer  and  Low 
Layer  as  used  in  this  Recommendation. 

These  comments  apply  to  network/terminal  functions  classification 
described  in  section  2  as  well  as  to  service  classification  described  in 
section  3. 

3.  Telecommunication  services  characterization 

3. 1  General 

A  telecommunication  service  is  provided  by  an  administrative,  RPOA, 
or  in  certain  circumstances,  with  the  cooperation  of  private  companies.  A 
service  definition  usually  relates  to  network  and  terminal  functions. 

However,  1.2  ...  Recommendations  characterize  ISDN  telecommunication  services 
at  reference  point  S  or  T.  Network  functions  are  explicity  defined  as  they 
appear  to  the  user.  Some  of  the  terminal  functions  are  implicitly  defined. 

Note  -  It  may  be  that  an  ISDN  provides  services  to  other  networks,  possibly 
not  at  reference  points  S  or  T.  This  requires  further  study. 

In  the  following  two  broad  categories  of  services  are  considered  : 

-  bearer  services,  and 

-  tele-services. 
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A  service  is  characterized  and  described  by  service  attributes. 

There  are  two  groups  of  service  attributes  appTicabTe  to  the  user  information 
flow  :  the  low  layer  attributes  (OSI  layers  1-3)  and  the  high  layer  attributes 
(OSI  layers  4-7).  Bearer  services  are  characterized  only  by  low  layer 
attributes.  Tele-services  are  characterized  both  by  low  layer  attributes  and 
high  layer  attributes. 

The  basic  characteristics  of  a  service  are  described  by  the  basic 
service  attributes.  The  additional  characteristics  of  a  supplementary  service 
are  described  by  additional  service  attributes. 

3.2  Bearer  services 

Bearer  services  provide  the  capability  for  information  transfer 
between  ISDN  interfaces  and  involves  only  functions  at  layer  1  and  possibly 
layers  2  and  3  within  ISDN.  The  customer  may  choose  any  set  of  high  layer  (at 
least  4-7)  protocols  for  his  communication,  and  the  ISDN  does  not  ascertain 
compatibility  at  these  layers  between  customers.  An  example  of  a  bearer 
service  is  a  64  kbit/s  circuit  switched  transparent  service. 

A  bearer  service  provides  the  user  with  the  possibility  of  getting 
access  to  various  configurations  of  communications,  covering  : 

information  transfer  between  users  employing  the  same  access 
attributes  at  the  S/T  reference  points  involved,  see  Figure  2a; 

information  transfer  between  users  employing  difference  access 
attributes  at  the  S/T  reference  points  involved,  see  Figure  2b; 

information  transfer  between  a  user  and  a  separate  resource  providing 
high  layer  functions,  see  Figure  2c. 

Bearer  services  are  characterized  by  a  set  of  Tow  layer  attributes 
defined  in  Recommendation  I.2xx.  Low  layer  attributes  describe  the 
communication  related  characteristics  of  a  service  (basic  low  layer 
attributes)  or  of  a  supplementary  service  (supplementary  low  layer 
attributes).  Low  layer  attributes  refer  to  the  functions  and  protocols  of  the 
layer  1  and  possibly  2-3  (OSI  reference  model)  concern  the  transfer  of  user 
information.  Attributes  defining  bearer  services  are  classified  into  three 
categories: 

information  transfer  attributes; 
access  attributes; 

general  attributes,  including  operational  and  commercial  attributes. 

The  bearer  capability  defines  the  technical  features  of  a  bearer 
service  as  they  appear  to  the  user.  For  the  time  being  the  bearer  capability 
is  characterized  by  information  transfer  and  access  attributes.  A  type  of 
bearer  capability  is  associated  to  every  bearer  service. 

Note  -  It  is  likely  that  some  quality  of  service  parameters  (attribute  number 
10  in  draft  Recommendation  I.2xx)  -  such  as  error  rate  or  call  set-up  delay  - 
should  be  extracted  in  order  to  form  a  new  attribute  allocated  to  the  category 
information  transfer.  Identification  and  definition  of  such  parameters 
requires  further  consideration. 


Access 
Attributes  A 


Access 
Attributes  A 
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Vv  .1 

KVO 


Access 

A 


Access 

B 


TE 


TE 


Layer  1  and  possibly  layers  2-3  functions 


Defined  by  information  transfer  attributes 


Note  1  -  Reference  point  to  be  defined  but  not  necessary  subject  to  CCITT 
Recommendations. 


Note  2  -  Further  study  is  required  on  bearer  services  extending  beyond  the 

T5WT 


Note  3  -  Further  study  is  required  on  possible  communications  involving  bearer 
services  with  different  values  allocated  to  information  transfer  attributes. 


FIGURE  2/1.200 


>les  of  bearer  service  operation 


Teleservices 


Teleservices  provide  the  full  capability  for  communication  by  means 
of  terminals,  network  functions  and  possibly  functions  provided  by  dedicated 
centres.  A  tele-service  is  characterized  by  a  set  of  low  layer  attributes,  a 
set  of  high  layer  attributes  and  operational  and  commercial  attributes.  Low 
layer  attributes  are  those  used  to  characterize  the  bearer  capability  (see 
section  3.2).  High  layer  attributes  are  defined  in  Recommendation  I.2xy. 

They  describe  message  (i.e.  messages  on  layer  7)  related  characteristics  of  a 
service  (basic  high  layer  attributes)  or  of  a  supplementary  service 
(supplementary  high  layer  attributes).  They  refer  to  the  functions  and 
protocols  of  the  layers  4-7  (OSI)  concerning  the  transfer,  storage  and 
processing  of  user  messages  (provided  by  a  subscriber's  terminal,  a  retrieval 
centre  or  a  network  service  centre).  Examples  of  teleservice  are  telephony 
and  teletext. 
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An  ISDN  teleservice  generally  uses  only  one  (or  a  small  number  of) 
types  of  bearer  capability,  which  should  be  recommended  by  CCITT  to  support  a 
given  teleservice.  It  should  be  noted  that  in  the  case  where  more  than  one 
type  of  recommended  bearer  capability  is  used  for  a  given  teleservice 
interworking  functions  may  be  required  under  the  responsibility  of  the 
teleservice  provided.  This  principle  does  not  prevent  a  user  operating  a 
specific  application  to  use  a  terminal  compatible  with  a  given  teleservice  in 
association  with  a  bearer  capability  not  recommended  for  this  teleservice. 

3.4  In  addition  to  services  that  clearly  fall  into  the  two  categories 
defined  above,  there  may  be  other  services  which  possibly  could  constitute  one 
or  more  further  categories.  Examples  of  such  services  might  be  services 
providing  information  handling  at  higher  layers  but  which  do  not  cover 
terminal  functions  in  addition  to  those  specified  by  the  protocol  at  the 
terminal  interface. 

The  possible  definition  of  an  additional  category  of  services  for 
such  services  is  for  further  study. 

4.  Relations  between  service  categories  and  functional  elements 

The  services  and  supplementary  services  are  realized  in  the  network 
and  the  terminals  by  the  ISDN  capabilities  and  terminal  capabilities,  i.e. 
basic  and  additioal  low  and  high  layer  functions.  These  functions  are 
composed  of  network  and  terminal  functions. 

Table  2/1.200  gives  an  overview  about  the  structure  of  and  the 
relation  between  service  attributes,  low/high  layer  functions,  and 
network/terminal  functions. 

Figure  3/1.200  gives  an  example  of  teleservice  operation  through  an 

ISDN. 

It  should  be  noted  that  for  a  telecommunication  service,  the 
terminals  may  provide  functions  similar  to  ALLF  or  MLF  supported  by  an  ISDN. 

Network  functions  are  specified  in  Recommendation  1.2  ...  . 

5.  Provision  of  telecommunication  services 

5.1  General 

Depending  on  the  nature  of  the  customer  ownership  within  the 
subscriber  premises  (TE,  or  TE  and  NT2)  a  telecommunication  service  is 
provided  at  S  or  T  reference  point. 
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Note  3  -  Definition  of  HLF  attributes  have  not  been  defended  and  require  FS. 

Note  4  -  Network  functions  are  defined  in  1.300  and  1.325. 

Notes  to  Table  2/1.200 

Note  1  -  Attributes  1-12  are  defined  in  Reconmendation  I.2xx. 

Note  2  -  A  supplementary  service  cannot  be  offered  as  a  stand  alone  entity. 

The  attribute  No.  9  is  mainly  concerned  by  supplementary  services  and  could  be 
split  into  sub-attributes  depending  on  results  of  further  studies. 

Supplementary  services  could  also  have  an  influence  on  basic  service 
attributes  (1-8,  10-12);  this  also  requires  further  consideration. 


Layer  1-3  functions 
Scope  of  Teleservices 


HLF  =  High  Layer  Functions 


FIGURE  3/1.200 


Examples  of  teleservices 


5.2  Provision  of  teleservices 

* 

A  teleservice  provider  offers  services  to  users 
insofar  as  it  knows  them  as  using  this  service,  for  instance,  and  makes 
arrangements  to  allow  open  communications  (in  addition  to  public  network 
capabilities  of  layers  1  to  3);  for  instance: 

-  registration  into  a  service  directory,  that 
corresponds  to  a  subscription  ensuring  the  service  access, 

-  provision  of  possible  HLF  allowing  for  instance 
some  interworking  capabilities  (eg.  Telex-  Teletex). 
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Some  aspects  of  Teleservice  Interworking 


An  administration  or  RPOA  may  provide  service  interworking 
between  certain  equipment  attached  to  the  networks.  Two  possibilities  should 
be  considered: 


i)  The  equipment  is  certified  as  consistent  with  standards 
relevant  to  the  networks  service,  in  which  case  appropriate  service 
interworking  is  available. 


ii)  The  equipment  is  recognized  as  being  able  to  be  connected 
to  the  network  without  disturbing  it.  In  this  case,  the  network  cannot 
necessarily  make  service  interworking  available. 
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Low  Layer  Function:  The  low  layer  functions  are  the  realization  of  the  low 
layer  attributes.  They  are  related  to  the  layers  1  to  3  (OSI).  They  may  be 
implemented  in  the  network,  terminals  or  both. 

There  are  distinguished  basic  low  layer  functions  (BLLF) ,  which  realize  the 
basic  low  layer  attributes  of  a  service,  and  the  additional  low  layer 
functions  (ALLF),  which  realize  the  supplementary  low  layer  attributes  of  a 
supplementary  service. 

High  Layer  Function:  The  high  layer  functions  are  the  realization  of  the  high 
layer  attributes.  They  are  related  to  the  layers  4  to  7  (OSI).  They  may  be 
implemented  in  the  network  (network  service  center),  terminals  (incl. 
retrieval  centers)  or  both. 

The  distinction  is  made  between  the  basic  high  layer  functions  (BHLF) 
realizing  the  basic  high  layer  attributes  of  a  service  and  the  additional  high 
layer  functions  (AHLF)  realizing  the  supplementary  high  layer  attributes  of  a 
supplementary  service. 


•  *•% 

•mI 


% 

$ 


•?>>>>>>>>>>: 


v'  %’  */v  -T  V 

v*  O  V' 


A.O  1  2 


«S 


CCITT 

STUDY  GROUP  XVIII 

Geneva,  21  November  -  2  December  1983 


Temporary  Document  44-E 


ANNEX  1 


NEW  DRAFT  RECOMMENDATION  I.2xx  (REVISED  VERSION  OF 
PART  II  OF  1.200  IN  COM  XVIII-R  20) 


Draft  Recommendation  I.2xx 


BEARER  SERVICES  SUPPORTED  BY  AN  ISDN 


Consider inc 


-  the  ISDN  concept  described  in  Recommendation  1.120, 

-  the  ISDN  functional  architecture  model  described  in  draft  Recommendation 

1.310, 

-  the  ISDN  protocol  reference  model  described  in  draft  Recommendation 

1.311, 

-  the  ISDN  connection  types  described  in  draft  Recommendation  I.3xx 

-  the  ISDN  user-network  interface  reference  configurations  described  in 
draft  Recommendation  1.411, 

-  the  principles  for  defining  ISDN  services  described  in  draft 
Recomnendation  1.200, 

an  ISDN  will  support  a  wide  variety  of  services.  The  purpose  of  this 
Recommendation  is  to  provide  a  description  of  such  services  to  be  used  as  a 
basis  for  defining  the  network  capabilities  required  by  ISDN. 

1.  Framework  for  describing  ISDN  bearer  services 

ISDN  bearer  services  are  described  by  a  number  of  attributes,  which 
are  intended  to  be  largely  independant.  They  are  grouped  into  three 
categories  : 

i)  Information  transfer  attributes,  which  characterize  the  network 
capabilities  for  transferring  information  from  one  S/T  interface  to 
one  (or  more)  other  S/T  interfaces; 

ii)  Access  attributes,  which  describe  the  means  for  accessing  network 
functions/facilities  as  seen  at  one  S/T  interface;  and 


iii)  General  attributes,  which  deal  with  the  service  in  general. 


Figure  1/I.2xx  shows  the  relation  between  the  groups  of  attributes 
and  the  parts  of  the  service  where  the  attributes  are  defined. 

Information  transfer  attributes 


S/T 


J 

i - * 

Access  attributes 


FIGURE  1/I.2xx 


Table  1/I.2xx  gives  the  list  of  the  attributes 

TABLE  1/I.2xx 

Information  transfer  attributes 

1  -  Information  transfer  mode 

2  -  Information  transfer  rate  (Note  1) 

3  -  Type  of  information  transfer  capability 

5  -  Establishment  of  communication 

7  -  Symmetry 

6  -  Information  transfer  configuration 

4  -  Structural  integrity 

Access  attributes  (Note  2) 

8  -  Access  channel  and  rate  (Note  1) 

9  -  Access  protocol 

General  attributes 

10  -  Supplementary  services/facilities  provided 

11  -  Quality  of  service 

12  -  Interworking  possibilities 

13  -  Operational  and  commercial 

Note  1  -  Attribute  2,  information  transfer  rate,  describes  the  rate  at  which 
information  can  flow  from  one  user  to  another.  Examples  are  bit  rate  for 
circuit  switched  services  and  throughput  for  packet  switched  services. 
Attribute  8,  Access  channel  and  rate,  describes  the  bit  rate  of  the  channel  at 
a  given  user-network  interface. 

Note  2  -  Different  access  attributes  may  apply  at  each  of  the  (two  or  more) 
network  interfaces  involved  in  the  use  of  a  bearer  service. 

Figure  2/1. 2xx  presents  a  list  of  possible  values  for  each 
attribute.  Where  options  exist  for  a  given  attribute,  the  section  is  subject 
to  agreement  between  the  customer  and  the  administration.  A  detailed 
descriptions  of  the  attributed  values  is  given  in  appendix  1  (see  TO. 45). 
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Possible  values  for  each  attribute 
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Description  of  bearer  services 


I 


This  section  describes  several  bearer  services  accessed  via  the 
standard  network  access  provided  by  an  ISDN.  The  identification  and 
description  of  possible  additional  services  such  as  subrate  services  are  left 
for  further  study. 

These  possible  additional  services  would  not  lead  to  adding 
additional  requirements  to  those  already  identified  for  physical 
characteristics  of  interfaces  to  be  applied  at  reference  points  S  and/or  T 
(see  draft  Recommendation  1.411). 

2.1  Circuit  mode  bearer  service 

These  ISDN  bearer  services  are  typically  characterized  by  the 
provision  of  user  information  over  one  type  of  channel  and  signalling  over 
another  type  of  channel. 

2.1.1  Circuit  64  kbit/s  unrestricted 

An  unrestricted  bearer  service  provides  information  transfer  without 
alterations  between  S/T  reference  points.  It  may,  therefore,  be  used  to 
support  various  user  applications.  Examples  include  : 

1)  speech; 

2)  multiple  subrate  information  streams  multiplexed  into  64  kbit/s  by  the 
user; 

3)  transparent  access  to  a  X.25  public  network  (1.472). 

User  information  is  transferred  over  a  B  channel,  signalling  is  provided  over 
a  D  channel. 

Attributes/values 

Information  transfer  attributes 

1.  Mode  :  Circuit 

2.  Rate  :  64  kbit/s 

3.  Information  type  :  Unrestricted 

4.  Structure  :  8  kHz 

5.  Establishment  :  Demand/reserved/permanent 

6.  Configuration  :  Point-to-point  (Note  1) 

7.  Symmetry  :  Duplex-symmetric/simplex 

Note  1  -  Multipoint  may  be  an  additional  configuration. 

Access  attributes 

8.  Access  channel  :  B  for  user  information,  D  for  signalling  (Note  2) 

9.  Access  protocol  :  I -series  for  D  channel 

Note  2  -  For  reserved/permanent  service  the  operational,  administrative  and 
maintenance  messages  related  to  these  services  may  be  conveyed  over  the  D 
channel. 


General  attributes 
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10.  Supplementary  services/facilities 
U.  Quality  of  service 

12.  Interworking  possibilities 

13.  Operational  and  commercial  aspects 


for  further  study 
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2.1.2  Circuit  64  kbit/s,  usable  for  speech  information  transfer 

This  service  is  similar  to  the  unrestricted  service  (2.1.1)  except 
that  the  digital  signal  at  the  S/T  reference  point  follows  the  international 
agreed  encoding  laws  for  speech  (i.e.  A-law,  u-law)  and  that  the  network  may 
use  digital  signal  processing  techniques,  such  as  echo  cancellation  and  low 
bit  rate  voice  encoding.  Hence,  it  integrity  is  not  assured. 

Attributes/values 

1-2  :  Same  as  2. 1. 1 

3  :  Information  type  :  Speech  (encoded  according  to  A-law,  u-law) 

4-9  :  Same  as  2.1.1 

10-13:  For  further  study  (may  be  different  from  2.1.1) 

Due  to  the  lack  of  time  the  following  bearer  service  descriptions  are 
not  aligned  yet  to  the  new  list  of  attributes.  They  are  : 

2.1.2  Circuit  54  kbit/s,  usuable  for  voice-band  data  information  transfer  - 
further  study 

2.1.3  384  kbit/s  leased-circuit  services 

These  services  provide  for  transport  (with  or  without  modification)*) 
of  384  kbit/s  user  information  offered  over  an  HO  channel.  Operational, 
administrative  and  maintenance  information  may  be  carried  over  a  D  channel. 

Attributes/Values 

Information  transfer  attributes 

1.  Mode  :  circuit 

2.  Rate  :  384  kbit/s 

3.  Symmetry  :  Duplex-symmetric/Duplex-asymmetric/Simplex 

4.  Configuration  :  point-to-point/point-to-multipoint 

5.  Transparency  :  transparent/non-transparent 

Access  attributes 

6.  Access  Channel  Type  and  Rate  :  HO  for  user  information 

D  for  0^-M  information 

7.  Access  protocol  :  I -series  protocol 

8.  Establishment  of  a  connection  non- switched/reserved 

General  attributes 

9.  SS/F  available  for  further  study 

10.  QOS  :  for  further  study 

11.  Interworking  possibilities  :  for  further  study 

12.  Operational  and  commercial  :  for  further  study 
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This  service  provides  for  transport  (without  modification)  of  7536  kbit/s  user 
information  offered  over  a  HIT  channel.  Operational,  administrative  and 
maintenance  information  may  be  carried  over  a  D  channel. 


Attributes/Values 
Information  transfer-attributes 
T  Mode:  circuit 

2.  Rate:  1536  kbit/s 

3.  Symmetry  :  two-way/one-way 

4.  Configuration  :  point-to-point/point-to-multipoint 

5.  Transparency:  transparent 

Access  attributes 

(k  Access  Channel  Type  and  Rate  :  H 1 1  for  user  information 

D  for  0AM  information 

7.  Access  protocol:  I -series  protocol 

8.  Establishment  of  connection:  switched  (on  demand)/reserved 

General  attributes 
For  further  study 


2.1.5  1920  kbit/s  switched  service 

This  service  provide  for  transport  (without  modification)  of  the  1920  kbit/s 
user  information  offered  over  a  H12  channel.  Operational,  administrative  and 
maintenance  information  may  be  carried  over  a  D  channel. 

Attribute/ Values 
Information  transfer-attributes 
V.  Mode:  circuit 

2.  Rate:  1536  kbit/s 

3.  Symmetry:  two-way/one-way 

4.  Configuration:  point-to-point/point-to-multipoint 

5.  Transparency:  transparent 
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Access  attributes 

L  *  ' 

6.  Access  Channel  Type  and  Rate: 

H 12  for  user  information 

D  for  0AM  information 

90 

7.  Access  protocol: 

I-series  protocol 

8.  Establishment  of  connection: 

switched  (on  demand)/reserved 

General  attributes 

m 

for  further  study. 

m 

2.2  Packet-mode  bearer  services 

These  bearer  services  involve  packet  handling  functions  (PHF). 
Depending  on  the  resources  of  the  local  access  which  are  involved,  three 
bearer  services  can  be  identified  : 


2.2.1  Virtual  circuits 


This  service  provides  for  transport  (without  modification)  of  user 
information  in  a  packet i zed  manner. 


Attributes/Values 


Information  transfer  attributes 


1. 

2. 


Mode 

Rate 


3. 

4. 

5. 


Packet  -  virtual  circuit 

Maximum  instantaneous  throughput  of  a  given  virtual  circuit  is 
less  than  or  equal  to  the  host  channel  rate 
Symmetry  :  Duplex-symmetric 
Configuration  :  point-to-point 
Transparency  :  transparent 


Access  attributes 


6. 


7. 

8. 


Access  channel  type  and  rate  :  logical  channel  within  B  or  D  channel. 
When  D  channel  is  used  maximum  packet  size  and  quality  of  service  may 
be  restricted. 

Establishment  of  connection  :  switched  virtual  circuit  or  permanent 
virtual  circuit 

Access  protocol  :  X.25  level  3  X.25  LAP  B  level  2  or  1.441  when  the 
virtual  circuit  is  carried  on  a  B  channel;  1.441  when  the  virtual 
circuit  is  carried  on  a  D  channel. 


Note  :  Virtual  circuits  on  a  D  channel  provided  by  other  access  protocols  are 
for  further  study. 


General  attributes 


9. 


Supplementary  services/facilities  available  :  for  further  study; 
candidates  include  those  specified  in  CCITT  Recommendation  X.2 

10.  Quality  of  service  :  for  further  study 

11.  Interworking  :  for  further  study 

12.  Operational  and  commercial  :  for  further  study 


■*.;  vr: 


.%  a: 


L' 


V 


.V.vV 


A .  0  1  9 


iV 


su: 


2.2.?  Connectionless  packet  service  on  a  D  channel 

This  service  might  be  provided  to  support  applications  such  as 
telemetry,  telealarm  and  telecontrol.  Further  studies  could  indicate  specific 
constraints  on  this  bearer  service,  such  as  technical  performance  or  user 
throughput;  it  can  however  be  envisaged  that  it  caters  also  for  other 
applications  (e.g.  credit  card  checking). 

Attributes/Values 


Information  transfer  attributes 

1.  Mode  :  packet  -  connectionless 

2.  Rate  :  the  maximum  rate  at  which  connectionless  packets  may  be 

transferred  is  less  than  or  equal  to  the  D-channel  rate 

3.  Symmetry  :  Simplex 

4.  Configuration  :  point-to-point 

5.  Transparency  :  transparent 

Access  attributes 

6.  Channel  type  and  rate  :  within  a  D  channel 

7.  Protocol  :  for  further  study 

8.  Establishment  of  connection  :  not  applicable 

General  attributes 

9.  Supplementary  services-facilities  available  :  for  further  study 

10.  Quality  of  service  :  for  further  study 

11.  Interworking  possibilities  :  for  further  study 

12.  Operational  and  commercial  :  for  further  study. 
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Temporary  Document  No.  32-E 


STUDY  GROUP  XVIII 


Geneva,  21.11  -  2.12.1983 
Question  1B/XVIII 

SOURCE:  WT3  drafting  group  on  Addressing 
TITLE:  Report  of  Meetings 


1.  This  drafting  Group  met  on  Nov  24-25  to  consider  issues  related  to  ISDN 
numbering  and  addressing.  The  group  was  chaired  by  Eric  Scace  (USA  GTE 
Telenet).  Among  the  contributions  considered  were  TB,  TC,  TJ,  SL,  SM,  VI,  and 
UF,  and  Temp.  1  from  SG  II. 

As  a  result  of  the  discussion,  an  updated  version  of  Rec.  1.320  was 
produced  and  is  attached  to  this  report. 

2.  Destination  Network:  It  was  agreed  that  the  SG  II  conclusion  that  a 
destination  network  identification  (when  needed)  is  included  inside  the 
national  ISDN  number.  No  firm  conclusions  were  reached  to  express  a 
preference  between  methods  1  and  2  for  including  this  identification,  which 
were  outlined  by  SG  II.  Method  3  is  not  applicable  when  the  destination 
network  designator  is  included  in  the  National  ISDN  number. 

3.  Subaddressing  and  DDI:  It  was  agreed  that  digits  for  DDI  are  included 
inside  the  ISDN  number. 

It  was  agreed  that  the  subaddress  would  be  supplied  to  and  deliver  by,  an 
ISDN  with  procedures  which  are  independent  of  the  actual  length  of  the 
subaddress.  In  other  words,  a  one-digit  subaddress  is  procedural ly  treated 
the  same  way  as  a  32-digit  subaddress  at  the  origination  and  destination 
user-network  interfaces. 

It  was  agreed  that  the  information  element  conveying  the  subaddress  is 
separate  from  the  information  element  conveying  user-user  information  at, 
e.g.,  call  establishment  time.  User-user  information  is  considered  to  be 
completely  unstructured,  while  the  subaddress  has  structure  and  format 
limitations.  This  conclusion  appears  consistent  with  the  existing  status  of 
Rec.  1.451  (Q.930) . 

It  was  agreed  that  it  shall  be  possible  to  distinguish  between  the  ISDN 
number  and  subaddress  in  all  cases.  Therefore,  a  function  shall  be  provided 
to  mark  the  end  of  the  ISDN  number.  Another  function  shall  be  provided  to 
mark  the  end  of  the  ISDN  address.  The  exact  definition  of  the  implementation 
of  this  function  is  left  to  the  responsible  Study  Groups.  For  example,  WP 
XI/6  has  defined  in  the  current  draft  Rec.  1.451  (Q.930)  for  conveying  the 
ISDN  number  and  subaddress  in  separate,  consecutive  information  elements. 

Each  element  is  identified  by  the  "type  of  address"  field  as  containing  a 
number  or  sub-address. 


It  was  agreed  that  not  all  calls  will  have  subaddress  information  to 
convey. 

The  charging  implications  of  carrying  various  sizes  of  subaddress  are  left 
for  Study  Group  Ill's  consideration. 

It  was  proposed  that  the  subaddress  may  also  be  structured  such  that  the 
first  portion  might  be  used  for  terminal  identification  without  using  DDI  or 
other  capacity  from  the  ISDN  number  space  (e.g.,  in  the  case  of  a  passive 
bus).  However,  most  organizations  did  not  agree  with  this  proposal.  Among 
the  concerns  raised  during  an  extensive  discussion  were  the  implications  on 
the  maximum  length  of  the  subaddress;  the  implications  on  the  ability  to  use 
the  subaddress  to  convey  OSI  NSAP  addresses;  the  view  that  such  a  terminal 
selection  function,  if  required,  should  be  done  within  the  ISDN  number;  and 
concerns  about  the  portability  of  such  passive  bus  TEs  which  have  to  memorize 
such  a  number. 

It  was  agreed  that  the  maximum  length  of  the  subaddress  shall  be  32 
decimal  digits. 

4.  Interworking. 

It  was  agreed  that,  for  calls  originated  by  ISDN  subscribers  to 
subscribers  on  other  types  of  networks,  the  destination  address  may  contain  a 
number  from  another  numbering  plan.  For  example,  a  call  to  a  PDN  subscriber 
may  be  placed  using  an  X.  121  address  as  the  destination  address.  To 
facilitate  this  interworking,  an  explicit  indication  of  the  pertinent 
numbering  plan  should  be  provided  in  the  address  information  elements  of  Rec. 
1.451,  Since  this  indication  can  be  conveyed  in  e.g.,  octet  3  along  the  type 
of  address,  there  appears  to  be  no  need  for  definition  of  prefix  or  escape 
digit  sequences  in  the  user-network  interface  procedure  for  interworking 
purposes. 

It  was  reaffirmed  that  the  single  stage  method  of  interworking  shall  be 
the  preferred  method;  SG  II  and  XI  are  requested  to  develop  procedures  to 
accomplish  single  stage  interworking. 

It  was  felt  that,  for  calls  from  subscribers  of  other  types  of  networks  of 
ISDN  subscribers,  the  definition  of  procedures  for  interworking  (including  the 
conveyance  of  the  ISDN  address)  should  be  developed  by  the  Study  Group 
responsible  for  each  type  of  other  network. 

The  provisional  maximum  length  of  the  ISDN  number  of  15  digits,  chosen  by 
SG  II,  seemed  generally  adequate  to  perform  the  functions  envisioned  for  ISDN 
numbers. 

5.  Prefix  and  escape  codes. 

It  was  agreed  that  there  appeared  to  be  no  need  for  prefix  or  escape 
codes/functions  to  be  defined. 


6.  Transit  network  selection  (when  permitted). 

It  was  noted  that  I. 451  provides  an  identification  of  selected  transit 
networks  (when  permitted)  in  information  elements  distinct  from  those 
information  elements  conveying  ISDN  addresses.  This  is  consistent  with  our 
earlier  agreements. 

7.  Other  topics. 

It  was  agreed  that,  in  principle,  when  Rec.  E.16n  becomes  available  as  a 
Recommendation,  Rec.  1.320  will  be  reviewed  to  removed  duplication  with  E.16n. 

It  was  agreed  that,  from  an  addressing  viewpoint,  mobile  subscribers  are 
like  fixed  subscribers;  i.e.,  mobile  subscribers  have  TEs,  reference  points  S 
and  T,  NT1,  and  may  have  NT2.  Therefore,  an  ISDN  number  has  the  same  ability 
to  unambiguously  identify  points  in  mobile  subscriber  premises  as  it  has  for 
fixed  subscriber  premises. 

After  an  detailed  discussion  in  an  editing  group,  it  was  recognized  that 
multipoint  configurations  have  certain  addressing  implications.  For  example, 
on  a  passive  bus,  should  it  be  possible  to  select  a  single  TE  solely  by 
addressing  information  (i.e.,  within  one  category  of  service,  compatibility, 
etc.)?  To  make  such  a  selection  appears  to  require  the  TE  to  store  and 
recognize  its  address.  Discussions  so  far  have  not  explicitly  excluded  such 
TE  capabilities.  But  many  participants  felt  that  TEs  should  not  be  obliged  to 
remember  their  address. 
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During  the  discussion,  it  was  agreed  to  place  $3  on  the  relationship 
between  OSI  NSAP  addresses  and  ISDN  addresses  in  an  Annex.  It  was  also  agreed 
that  ISDN  addresses  may  be  associated  with  applications  which  are  not  in  the 
"OSI  environment",  as  well  as  with  OSI  applications. 

It  was  agreed  that  further  study  is  needed  on  the  principles  for 
describing  how  a  call  is  routed  to  a  user,  based  on,  e.g.,  addresses, 
compatibility  information,  service  identification,  etc.  Therefore, 
contibutions  on  this  topic  are  solicited,  including  aspects  of  call  delivery 
such  as  closed  user  groups,  for  beginnning  the  development  of  Rec.  1.321  on 
routing  principles. 
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Draft  Recommendation  1.320 

ADDRESSING  AND  NUMBERING  PRINCIPLES  IN  ISDN 


1.  Introduction 

I.T  This  recommendation  provides  the  general  concepts,  principles,  and 

requirements  for  addressing  reference  points  located  at  subscriber  premises, 
for  addressing  other  functions,  and  for  allowing  communications  with  TEs. 
This  recommendation  defines  the  requirements  for  applying  the  numbering  plan 
to  ISDN. 


Further  study  is  required  on  the  principle  of  describing  how  a  call 
is  routed  to  a  user  based  on,  e.g.,  address  and  service  indication,  (see  Rec. 
1.321) 

1.2  The  following  understanding  of  relevant  nomenclature  is  established: 

a.  an  ISDN  number  is  one  which  relates  to  an  ISDN  network  and  ISDN 
numbering  plan. 

b.  an  ISDN  directory  number  is  that  which  may  be  listed  in  public 
directories  against  the  subscriber's  name. 

c.  an  ISDN  address  comprises  the  ISDN  number  and  the  mandatory 
and/or  optional  additional  addressing  information. 

d.  private  communications  facilities  are  communications  capabilities 
confined  to  use  by  one  or  more  particular  subscribers,  as  opposed  to 
facilities  which  are  shared  by  subscribers  of  public  networks.  Examples  of 
private  communications  facilities  include  LANs,  PABXs  and  other  private 
network  arrangements. 

1.3  Depending  on  the  different  cases  and  stages  identifiable  within  an 
addressing  process,  an  ISDN  number  may  be  : 

a.  an  international  ISDN  number,  or 

b.  a  national  ISDN  number,  or 

c.  an  ISDN  subscriber  number. 

An  ISDN  address  comprises  : 

d.  the  ISON  number,  and 

e.  mandatory  and/or  optional  additional  addressing  information. 

1.4  As  an  objective,  all  ISDNs  should  evolve  towards  a  single  numbering 
plan,  namely  the  ISDN  numbering  plan.  Considering  the  wide  penetration  of  the 
telephone  network  in  the  world  and  its  existing  resources,  the  ISDN  numbering 
plan  should  be  developed  by  enhancing  Recommendation  E . 163.  Therefore,  it  is 
recommended  that  the  telephone  country  code  (TCC)  be  used  to  identify  a 
particular  country*. 

1.5  An  existing  numbering  plan  may  interwork  and  thus  coexist  with  the 
ISDN  numbering  plan.  All  interworking  cases  from  ISDN  to  dedicated  networks, 
and  vice  versa,  have  to  be  covered  by  the  appropriate  Study  Groups. 

Preference  should  be  given  to  single  stage  selection  methods  whenever  possible. 
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It  is  recognized  that  some  of  the  present  data  networks,  for 
instance,  could  retain  the  X.I2I  numbering  structure  and  interwork  with 
ISONs.  Necessary  interworking  arrangements  should  be  studied  for  securing 
interconnectability  between  ISDNs  employing  the  ISDN  numbering  plan  and  e.g., 
multiple  service  networks  evolving  from  data  networks  using  the  X.121 
numbering  structure. 

2.  Principles  for  Relating  an  ISDN  number  to  ISDN  User-Network  Reference 

Configurations 

2.1  An  ISDN  number  shall  be  able  to  unambiguously  identify  a  particular: 

a.  physical  interface  at  reference  point  T.  See  Figure  1/1.320 

b.  virtual  interface  at  reference  point  T;  i.e.,  for  a  NT2+NT1 
configuration.  See  Figure  2/1.320. 

c.  Multiple  interfaces  (physical  or  virtual)  at  reference  point  T. 

See  Figure  3/1 .320. 

d.  for  point-to-point  configurations,  physical  interface  at 
reference  point  S.  See  Figure  4/1.320. 

e.  for  point-to-point  configurations,  virtual  interface  at  reference 
point  S.  See  Figure  5/1.320. 

f.  for  point-to-point  configurations,  multiple  interfaces  (physical 
or  virtual)  at  reference  point  S.  See  Figure  6/1.320. 

g.  for  multi-point  configurations  (e.g.,  passive  bus),  all  of  the 
interfaces  are  reference  point  S.  See  Figure  7/1.320.  It  was  agreed  after  a 
review  of  the  potential  uses  of  ISDN  addresses  that,  from  the  viewpoint  of  the 
network  side  of  the  interface,  an  ISDN  address  is  associated  with  one  (or  a 
multiple  of)  D-channel  used  to  signal  to  the  user. 

Note  -  The  ability  to  select  one  TE  in  a  multi-point  configuration  (e.g., 
passive  bus)  solely  by  address  information  is  for  further  study. 

2.2  A  particular  interface,  or  multiple  of  interfaces,  may  be  assigned 
more  than  one  ISDN  number.  An  example  is  shown  in  Figure  8/1.320. 

2.3  All  ISDNs  shall  be  able  to  assign  an  ISDN  number  to  an  interface  at 
reference  point  T  or  S.  However  a  particular  ISDN  number  fulfills  only  one  of 
the  functions  identified  in  2.1  above. 

2.4  For  mobile  services  an  ISDN  number  shall  be  capable  of  unambiguously 
identifying  an  interface  in  the  mobile  subscriber's  premises,  as  defined  in 
Section  2.1  See  Figure  8/1.320. 

2.5  The  ISDN  number  is  not  required  to  identify  a  particular  connection 
where,  on  a  particular  interface,  more  than  one  connection  may  be  present  at  a 
given  instant. 

2.6  The  ISDN  number  is  not  required  to  identify  directly  a  particular 
channel,  where,  within  a  particular  interface,  there  may  be  more  than  one 
channel.  Indirect  identification  of  particular  channels  may  occur;  e.g.,  when 
the  ISDN  number  identifies  a  particular  interface  and  there  is  a  one-to-one 
correspondence  between  that  interface  and  particular  channels. 
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3.  Relationships  between  ISDN  number  transit  network/880A  selection 
(when  permitted),  service  indication,  and  quality  of  service  indication. 

The  establishment  of  an  ISDN  connection  will  require  an  ISDN 
address.  In  addition,  separate  non-address-related  information  may  be 
necessary  for  completing  a  connection. 

3.1  Routing  of  ISDN  connections  shall  take  into  account  the  following 
information,  when  supplied  by  the  user  : 

a.  ISDN  numbers,  including  destination  network  identification 
(network  identification  code,  NIC)  and  digits  for  direct  dialling  in  (DDI) 
where  applicable. 

b.  service  identification,  possibly  including  requested  quality  of 
service  parameters  such  as  transit  delay  throughput,  and  security. 

c.  multiple  transit  RPOA/network  selections,  when  permitted. 

Note:  The  need  for  remote  transit  RPOA/network  selection  by  the  user 
of  an  ISON  which  has  no  local  transit  RPOA/network  selection  is  for  further 
study. 

Transit  RPOA/network  selection  by  the  user,  when  permitted,  or  by  the 
originating  ISDN,  shall  be  evaluated  in  the  routing  of  a  connection. 

In  national  networks  on  a  particular  connection,  the  user  may  choose  to 
specify  some  or  all  of  this  information,  at  either  subscription  time  or 
connection-establishment  time. 

The  ISDN  number  does  not  identify  the  particular  nature  of  the 
service,  type  of  connection,  or  quality  of  service  to  be  used,  nor  transit 
RPOA/network. 

3.2  In  the  case  where  an  ISDN  number  identifies  a  mobile  TE  or  a  TE 
served  by  several  interfaces  or  networks,  an  ISDN  may  need  to  map  from  the 
ISDN  number  into  a  specific  interface  designation. 

4.  ISDN  Number  Design  Considerations 

Note:  Numbering  Plan  design  information  covered  by  Recommendation 
E.15m  will  be  deleted  when  Recommendation  E.16m  becomes  available. 

4.1  The  ISDN  number  shall  include  an  unambiguous  identification  of  a 
particular  country*). 


or  geographic  area. 
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The  ISDN  number  is  allowed  to  include  an  unambiguous  identification 
of  a  particular  geographic  area  within  a  country.  *) 

4.2  As  an  objective,  all  ISDNs  should  evolve  towards  a  single  numbering 
plan.  However,  an  existing  numbering  plan  may  interwork  and  thus  coexist  with 
the  ISDN  numbering  plan. 

4.3  When  a  number  of  public  or  private  ISDNs  exist  in  a  country,  it  shall 
not  be  mandatory  to  integrate  the  numbering  plans  of  the  ISDNs.  Methods  for 
interworking  are  for  further  study,  with  the  objective  that  connections 
between  the  TEs  on  these  various  networks  can  be  completed  by  using  only  the 
ISDN  address. 

4.4  The  ISDN  number  shall  be  capable  of  containing  an  identification  of 
the  ISDN  to  which  the  called  user  is  attached.  For  a  private  network  which 
spans  more  than  one  country,  the  country  code  will  cause  delivery  of  a 
connection  in  the  specified  country  to  the  particular  private  network. 

4.5  The  ISDN  number  shall  be  capable  of  providing  for  interworking  of  TEs 
on  ISDNs  with  "TEs"  on  other  networks.  As  an  objective,  with  respect  to  the 
ISDN  number,  the  procedure  for  interworking  should  be  the  same  for  all  cases. 
The  single-stage  method  of  interworking  is  the  preferred  approach. 

5.  Structure  of  the  ISDN  address 


5.1  The  structure  of  the  ISDN  address  is  illustrated  in  Figure  10.  A 
function  marking  the  end  of  the  ISDN  number  shall  always  be  provided,  even 
when  no  subaddress  is  present.  An  end  of  address  is  also  required.  When 
there  is  no  subaddress  present,  the  end  of  number  and  end  of  address  functions 
are  coincident. 

5.2  The  ISDN  address  shall  be  a  sequence  of  decimal  digits.  The  ISDN 
number  shall  include  the  capability  of  Direct  Dialing  In. 

5.3  The  ISDN  address  may  be  of  variable  length. 

5.4  International  ISDN  number. 

5.4.1  The  international  ISDN  number  may  be  of  variable  length.  Minimum  and 
maximum  lengths  should  be  prescribed  and  are  for  further  study.  A  reasonable 
limit  on  the  overall  number  of  digits  shall  be  imposed. 

5.4.2  In  a  particular  international  ISDN  number,  the  exact  number  of  digits 
shall  be  governed  by  national  and  international  requirements. 

5.4.3  The  ISDN  numbering  plan  shall  provide  substantial  spare  capacity  to 
accommodate  future  requirements. 

5.5  ISDN  sub-address 

5.5.1  All  ISDNs  shall  be  capable  of  conveying  the  ISDN  sub-address 

transparently. 

5.5.2  Special  attention  is  drawn  to  the  fact  that  sub-addressing  is  not  to 
be  considered  as  part  of  the  numbering  plan,  but  constitutes  an  intrinsic  part 
of  the  ISDN  addressing  capabilities.  The  sub-address  shall  be  conveyed  in  a 
transparent  way  as  a  separate  entity  from  both  ISDN  number  and  user-to-user 
information.  A  maximum  length  shall  be  32  decimal  digits. 


6. 


Representation  of  ISDN  address 


6.1  At  the  person-machine  interface,  the  objective  is  to  establish  one 
method  of  distinguishing  between  abbreviated  and  complete  representations  of 
an  ISDN  number.  This  method  is  for  further  study.  International  recommended 
methods  will  be  chosen. 

6.2  The  method  to  distinguish  between  an  ISDN  number  and  a  number  from 
another  numbering  plan  shall  be  by  a  separate  identification  of  the  applicable 
numbering  plan.  If  such  methods  are  required,  international  recommended 
procedures  will  be  chosen. 


ANNEX  A 

(to  Recommendation  1.320) 

Interworking  with  dedicated  networks 

Al.  At  an  interface  between  an  ISDN  and  a  dedicated  bearer  service  public 
network,  the  interworking  unit  shall  convert  between  ISDN  addresses  and 
dedicated  bearer  service  network  numbers,  when  required. 

A2.  TEls  are  always  allowed  to  use  ISDN  numbers  when  originating  a 
connection.  Some  ISDNs  may  also  allow  other  numbers  to  be  used.  In  this  case 
such  numbers  shall  be  conveyed  with  an  identification  of  the  relevant 
numbering  plan. 

A3.  When  a  TE2  call  user  of  an  existing  dedicated  bearer  service  network, 
the  TE2  may  use  the  dedicated  bearer  service  number.  In  the  case  of  a  TE2 
placing  an  outgoing  call  via  an  ISDN  which  uses  only  the  ISDN  numbering  plan, 
the  dedicated  bearer  service  number  will  be  converted  into  an  ISDN  number. 

A4.  When  a  terminal  on  a  dedicated  bearer  service  network  calls  an  ISDN 
interface  which  has  been  assigned  an  ISDN  number,  the  terminal  on  the 
dedicated  bearer  service  network  must  use  the  appropriate  dedicated  bearer 
service  procedure  for  indicating  the  ISDN  address.  This  procedure  should  be 
developed  by  the  study  group  reponsible  for  that  dedicated  bearer  service 
network. 


ANNEX  B 

(to  Recommendation  1.320) 

Principles  Relating  ISDN  Numbers  to  the  X.200  Reference  Model 
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In  the  X.200  reference  model,  addresses  identify  service  access 
points  at  each  layer.  As  the  essential  purpose  of  the  Network  Layer  is  to 
achieve  routing  of  information  within  the  Open  Systems  Interconnection 
Environment,  the  ISDN  number  has  to  be  related  to  the  X.200  Network  Layer 
Service  access  point,  when  needed.  There  are  also  cases  where  an  ISDN  address 
identifies  a  non-OSI  end  system. 

The  ISDN  address  includes  the  OSI  network  layer  address,  and  thus 
provides  the  capability  to  identify  OSI  network  layer  service  access  points. 

When  needed,  the  ISDN  number  is  related  to  the  OSI  network  layer 
address  according  to  the  following  methods  : 

a)  For  some  OSI  network  layer  addresses,  the  ISDN  number  is 
identical  to  the  OSI  network  layer  address. 

b)  For  other  OSI  network  layer  addresses,  the  ISDN  number  is 
contained  in  the  OSI  network  layer  address.  The  remainder  of 
the  OSI  network  layer  address  is  conveyed  in  the  ISDN 
sub-address. 

c)  For'the  remaining  OSI  network  layer  addresses,  the  ISDN  number 
may  be  derived  from  the  OSI  network  layer  address.  The  entire 
OSI  network  layer  address  can  also  be  conveyed  in  the  ISDN 
sub-address. 

The  ISDN  address  is  not  directly  related  to  a  physical,  data  link, 
transport,  session,  presentation  or  application  layer  entity,  entity  instance, 
or  service  access  point.  Indirect  relationships  may  occur  as  one  or  some  of 
these  entitites  or  service  access  points  may  be  in  correspondence  with  network 
layer  service  access  points. 
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CCITT  Temporary  Document  34-B 

STUDY  GROUP  XVIII 

Geneva,  21  November  -  2  December  1983 

Question  :  1/XVIII,  p.B 

SOURCE  :  CHAIRMAN,  WORKING  TEAM  3 

TITLE  :  ISDN  -  NETWORX  FUNCTIONAL  PRINCIPLES  i-£,3OCl  ) 


In  deliberations  over  the  weekend  on  the  draft  of  the  ISDN  Functional  Model 
prepared  by  M.  Jezequel  for  inclusion  into  I . 311 ,  the  suggestion  was  made  to  retain 
a  separate  document. 

The  new  document  is  proposed  as  an  overview  and  introduction  of  the  network 
series  of  Recommendations  to  be  called  1.300.  A  draft  of  1.300,  based  on  M.  Jezequel' s 
text  is  attached  for  discussion. 

Draft  Recommendation  1.300 

ISDN  -  NETWORK  FUNCTIONAL  PRINCIPLES 


1.  General 


This  Recommendation  outlines  the  functional  principles  of  the  network  aspects 
of  the  ISDN  as  an  introduction  to  the  network  series  of  Recommendatons  on  the  ISDN. 

The  objective  of  this  Recommendation  is  to  provide  a  common  understanding 
of  the  ISDN  network  series  of  Recommendations  by  developing  functional  groupings 
of  ISDN  capabilities  and  their  respective  relationships. 

2.  Relationship  with  other  I-series  Recommendations 

The  ISDN  is  defined  in  Recommendation  1.120.  The  services  supported  by 
an  ISDN  are  given  in  the  1.200  series  of  Recommendations.  The  network  capabilities 
are  defined  in  the  1.300  series  of  Recommendations.  The  key  network  Recommendations 
and  the  relationship  between  them  is  shown  in  Figure  1. 
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3.  Network  functional  entitles 

The  design  of  an  ISDN  will  be  evolutionary,  adding  capabilities  in  a 
flexible  and  modular  form.  The  ISDN  may  therefore  be  expected  to  provide  an  open- 
ended  set  of  functional  capabilities  able  to  accommodate  new  needs  as  they  arise 
at  acceptable  cost. 

To  achieve  these  functional  objectives,  the  ISDN  functional  description 
has  been  designed  to  : 

-  define  the  overall  characteristics  of  the  ISDN; 

-  be  implementation  independent  and  place  no  constraints  on  national  network 

architectures  beyond  the  network  and  interface  standards  given  in  the  I-series 

of  Recommendations; 

-  take  full  account  of  the  constraints  of  existing  dedicated  networks; 

-  support  the  layering  concepts  defined  in  X.200. 

During  a  long  lnta  mediate  period,  eoae  features  any  not  be  lnpleaented 
within  a  given  ISDN.  Also  specific  arrangements  should  be  used  in  order  to  ensure 
compatibility  with  existing  networks  and  services.  These  features  and  arrangements 
are  specified  within  section  5  (Part  III)  of  the  I-series  of  Recommendations.  ISDN 
should  also  give  access  to  existing  services  and  interwork  with  existing  networks  and 
terminals;  in  some  countries  this  situation  is  likely  to  exist  even  in  a  very  long 
tern. 

The  ISDN  network  functional  entities  may  be  broadly  classified  into  the 
following  groups  s 

a)  Transport  functions  -  comprising  : 

-  Information  transfer  functions  (connections); 

-  Connection  control  functions; 

-  Management  and  operating  functions; 

-  Additional  lower  layer  functions; 

b)  Higher  layer  functions. 

These  functional  groupings  are  shown  in  Figures  2  and  3- 

A  general  classification  of  ISDN  functions  into  the  layers  defined  in 
X.200  is  shown  in  Figure  4. 
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User  system 


Note  (1)  Network  control  fAciliti.es  perform  such  functions  as,  for 
example,  closed  user  group  registration.  These  are  owned 
by  network  operators. 

(2)  Information  processing/messaging  facilities  include  data 
*»«••  facilities.  These  may  or  stay  not  be  owned  by  network 
operators . 

FIGURE  2 

Network  functional  entities 
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CCF  =  Connection  control  function 
ITF  =  Information  transfer  function 
MF  =  Management  and  operating  function 
Services  functions  may  be  distributed . 


FIGURE  3 

Network  functional  entities-schematic 
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APPLICATION  -  RELATED  FUNCTIONS 
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FIGURE  4 

ISDN  functions  allocated 
according  to  layering  principles  of  X.200 
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Transport  functional  entities 


ISDN  transport  functional  entities  may  be  described  by  the  connection 
requirements,  including  control,  management  and  performance  requirements,  between 
interfaces  across  an  ISDN. 


The  set  of  functions  which  characterize  connections  in  the  ISDN  is  based  on 
the  following  approach  : 


a)  Given  a  service  request,  which  is  characterized  by  a  set 
of  attribute  values,  the  appropriate  connection  type(s)  to 
support  it  must  be  identified. 


Service  Request  Examination 


-  Input  :  Service  request  *  set  of  attribute 

values 

-  Process  :  Examine  service  request  and  determine 

appropriate  network  connection  type(s) 

-  Output  :  Network  connection  type(s) 


set  of  attribute 


Once  selected,  the  connection  type  (which  has  end-to-end 
significance)  must  further  be  broken  down  koto  one  or  more 
smaller  components  called  “connection  element".  For 
example,  a  circuit-switched  call  reguicina  a  database 
query  would  imply  several  connection  element  such  as  CCS  ' 
packet  connections  and  Layer  1  connection  through  poten¬ 
tially  several  circuit  switches. 


Connection  element  selection 


-  Input 

-  process 


Connection  type 

Determine  connection  element(s)  to 


Output 


implement  connection  type 
Connection  element (s) 


c)  Each  connection  element  would  require  a  set  of  network  functions 
in  order  to  be  established. 


Function  Set  Determination 


-  Input 

-  process 


-  Output 


Connect  ion  element 

Select  appropriate  functions  to 
establish  connection  element 
Set  of  functions 


.  •  .  •  .v.v 


TEMP.  34-E 


The  association  of  two  network  transport  entities  and  the  corresponding 
control  functions  (including  protocols)  constitutes  a  network  connection  element. 

The  transport  functional  entities  are  shown  in  Figure  5. 


NtX  1>J  sift  Cv 


a) 


-> 


2)  Protocols  associated  can  be  in-band  or  out-band  (see  Recommendation  1.311). 

3)  The  CE  (connection  element)  used  here  is  a  pure  functional  concept. 

The  relationship  between  the  concepts  used  in  I.3xx  (to  be  introduced  in 
I.3xx)  needs  further  study. 

3.2  High  layer  functional  entities 

The  same  principles  of  classification  can  be  applied  in  the  case  where  higher 
layer  functions  are  involved,  i.e.  in  relation  with  telecommunication  services. 

The  translation  of  the  principles  described  in  section  3  leads  to  the  concent 
of  reap,  telecommunication  functions  and  high  layer  functions. 

The  high  layer  functions  may  be  centralized  in  a  special  nodes  or  distributed 
for  example  in  switching  nodes  or  terminals  (refer  Figure  7). 

4.  Internetwork  interfaces 


An  ISDN  may  comprise  a  number  of  networks,  i.e.  a  network  of  networks. 
Typical  examples  include  the  interface  of  national  networks  to  other  national  or 
international  networks .  Similarly  the  interface  of  an  ISDN  is  dedicated  to  networks 
or  private  networks . 

Additionally,  an  ISDN  may  comprise  transport  and  HLF  entities.  Where  some 
of  the  ALLF  or  HLF  functions  are  provided  outside  the  network,  further  interfaces 
are  identified. 

Internetwork  interface  definitions  are  necessary  for  these  arrangements 
for  administrative  and  interworking  requirements. 

Some  typical  internetworking  interfaces  are  shown  in  Figure  6. 


TEMP.  34-E 


5.  Basic  ISDN  architecture 

A  simple  ISDN  architecture  is  shown  in  Figure  7. 

The  objective  of  Figure  7  is  to  provide  an  introduction  to  ISDN  functional 
architecture  and  protocol  reference  models,  and  the  relationship  between  network 
functional  entities  and  network  protocols. 

Figure  7  viewed  from  the  top  describes  the  network  architecture  of  the  model. 

Figure  7  viewed  from  the  front  describes  the  protocol  configuration  between 
node  entities  across  the  network.  Taking  a  longitudinal  cross-section,  A-A  describes 
the  protocol  configuration  between  the  network  entities  intersected. 

Taking  a  cross-section  through  an  interface  as  for  example  B-B  describes 
the  protocol  interactions  between  layers  at  that  interface . 

Figure  7  -  to  be  added. 
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Documents  available 


1.310  part  A 

1.311 
I.3xx 

Delayed  Contribution  UV 
Delayed  Contribution  SG 
Delayed  Contribution  SH 
Delayed  Contribution  SI 


Report  of  the  meetlr 


The  Delayed  Contribution  UV  was  examined  in  detail.  New  concepts  are 
proposed  in  this  document.  In  fact  it  constitutes  a  complete  new  text  based  on  an 
approach  different  from  the  existing  one  in  1.310. 


Some  difficulties  were  encountered  to  reach  a  common  understanding  in  the 


group . 


As  a  consequence,  it  was  decided  to  base  the  discussion  on  the  existing  text, 
the  first  intention  being  to  improve  it  with  inputs  comming  from  Delayed 
Contribution  UV. 


After  a  detailed  examination  of  the  existing  text  it  was  decided  to  adopt  a 
new  plan  in  order  to  introduce  new  sections  deeding  with  a  more  detailed  description  of 
the  functions  used  to  build  the  different  functioned  concepts  already  identified 
( connections  elements ) . 


It  is  recognized  that  the  terminology  used  in  this  Recommendation  may  need  to 
be  edigned  with  the  terminology  used  in  other  Recommendations. 


Plan  proposed 


A  new  text  giving  the  general  objectives  of  this  Recommendation. 


1.  Introduction 


A  diagram  showing  the  relationship  between  the  different  1.3. •  Recommendations 
was  introduced. 


Connection  elements  and  functions 


2.1  General 


2.2  Function  set  determination 


based  on  existing 
text 


2.3  Super  set  of  functions 
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3.  Classi fication  of  functions 
New  section. 

4.  Network  functional  entity 
New  section. 

5.  Application  connection 
New  section. 

4.  New  text 


The  new  text  is  given  in  an  Annex  to  this  document. 

The  work  done  should  be  used  as  a  framework  for  the  drafting  and  editorial 
comments  taking  into  account  the  work  of  the  Connection  Group  and  protocols. 

Functions  of  ISDN 

This  recommendation  applies  to  ISDN’s  as  defined  by  the  I  series 
recommendations.  The  concepts  introduced  in  this  recommendation 
are  based  on  1.120,  where  the  ISDN  concept  is  described  and  de¬ 
fined  and  1.200  which  describes  services  that  are  supported  by  an  ISDN. 


The  objective  of  this  recommendation  is  to  provide  a  common 
understanding  and  a  description  of  ISDN  capabilities.  Consequently 
it  constitutes  the  basis  for  the  introduction  of  1.3. .  recommen¬ 
dations  (I.3XX,  1.311  etc.). 

This  recommendation  is  structured  as  follows: 

1)  An  introduction  gives  the  basic  principles  used  to  describe 
the  ISDN  capabilities  and  the  relationship  with  other  recommen¬ 
dations. 

2)  A  functional  description  principle  of  ISDN  capabilities  (Part  a). 

3)  An  architectural  description  (part  B,  text  f°r  further  study). 

The  principles  described  in  this  Recommendation  are  not  intended  to  preclude  or 
inhibit  any  implementation  of  ISDN. 

1.  Introduction 

ISDN  is  defined  as  a  network  consisting  of  a  limited  set  of  network  connection 
types  and  possibly  additional  functions  in  order  to  support  a  wide  range  of  bearer  or 
telecommunication  services  and  possible  supplementing  services  (facilities).  ISDN 
capabilities  are  described  in  various  I-series  Recommendations.  Figure  1  shows  one 
possible  grouping  and  the  relationships  between  some  of  these  Recommendations. 
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2.  Connections .  connection  elementa  and  functions 

ISDN  capabilities  need  to  be  described  in  such  a  way  that  takes  account  of 
the  fact  that  an  ISDN  will  be  required  to  support  new  services  and  supplementary 
services  as  the  need  arises. 

In  order  to  achieve  this  requirement  the  functional  classification  outlined 
is  intended  to  be  as  flexible  as  possible  and  provides  a  framework  of  concepts  which  i 

1)  are  implementation  independent; 

2)  allow  for  the  constraints  of  existing  networks; 

3)  cover  all  aspects  of  ISDN  functions; 

4)  is  in  line  with  OSI  RM  philosophy  (layering). 

In  order  to  achieve  these  requirements  the  approach  used  in  the  Recommendation 
is  to  identify  as  the  smallest  functional  unit  of  the  ISDN  functional  architecture 
network  functions  and  to  use  combinations  of  these  functions  to  build  network 
connections  as  described  in  I.3xx  and  additional  low  layer  functions  (ALLF)  and  higher 
layer  functions  (HLF)  which  support  supplementary  services/facilities.  In  I.3xx 
describing  ISDN  network  connection  types,  smaller  units  of  connection  have  been 
identified  called  connection  elements  and  these  can  also  be  described  in  terms  of 
set  of  network  functions. 

2.1  Function  set  determination 

A  network  connection  type  can  be  defined  by  a  set  of  functions  characterizing 
the  ISDN  capability  to  provide  suitable  means  for  the  transplex  of  data  between  two 
interfaces . 

The  determination  of  the  appropriate  set  of  functions  is  based  on  a  three 
step  approach  : 

i)  Given  a  service  request,  which  is  characterized  by  a  set 

of  attribute  values,  the  appropriate  connection  type(s)  to 

support  it  nust  be  identified. 
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Service  Request  Examination 

-  Input  :  Service  request  =  set  of  attribute 

values 

-  Process  :  Examine  service  request  and  determine 

appropriate  network  connection  type(s) 

-  Output  :  Network  connection  type(s) 

ii)  Once  selected,  the  connection  type  (which  has  end-to-end  significance) 
must  further  be  broken  down  into  one  or  more  smaller  components  called 
"connection  element". 


Connection  element  selection 

-  Input  :  Connection  type 

-  Process  :  Determine  connection  element(s)  to 

implement  connection  type 

-  Output  :  Connection  element(s) 


iii)  Each  connection  element  would  require  a  set  of  network  functions  in  order 
to  be  established. 


Function  Set  Determination 

-  Input  :  Connection  element 

-  Process  :  Select  appropriate  functions  to 

establish  connection  element 

-  Output  s  Set  of  functions 

2.2  Superset  of  functions 

The  functions  mentioned  above  belong  to  a  superset  of  functions  which  may  be 
called  upon  from  time  to  time  by  the  network  in  order  to  support  a  wide  range  of 
services  and  facilities  (bearer  service,  telecommunications  services,  interworking 
situations  between  services,  etc.).  This  superset  is  illustrated  in  figure  2,  in 
which  the  functions  are  structured  in  a  form  corresponding  to  the  Beven  layers  of  the 
OSI  model. 
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Superset  of  functions 
3.  Classification  of  functions 

The  functions  are  classified  in  two  classes,  the  lower  layer  functions  (LLF) 
corresponding  to  layers  1  to  3  of  the  OSI  model  and  the  higher  layer  functions 
corresponding  to  layers  4  to  7  (HLF)  (see  Figure  3)* 


FIGURE  3 
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Lower  layer  functions  are  sub-divided  into  two  categories  : 

i)  the  bearer  functions  (BF)  supporting  the  connection  elements; 

ii)  the  additional  lower  layer  functions  (ALLF)  supporting  additional  services 
(e.g.  facilities). 

The  bearer  functions  correspond  to  : 

handling 

routing 

-  management  and  operating  functions 

-  data  transfer  functions  (multiplexing,  segmenting  and  blocking,  sequencing 

etc.,  ..  Refer  to  X.200) 

4-  Network  functional  entity  (or  functional  grouping) 

A  network  functional  entity  is  defined  as  being  a  set  lower  layer  functions 
relating  to  a  connection  element.  The  association  of  two  network  functional  entities 
and  the  corresponding  peer  protocols  constitutes  the  connection  element  (Figure  4) • 

As  a  consequence,  a  connection  element  is  delimited  by  protocol  breakpoints  (generally 
at  level  3). 


Call  control 
functions 


.Connection 


Network 
functional 
entity  A 


Network 
functional 
entity  B 


FIGURE  4 


Connection  element 


Depending  on  implementation  considerations,  a  network  functional  entity  can  be  built 
with  : 


bearer  functions  only; 


-  bearer  functions  and  additional  lower  layer  functions. 

During  a  long  intermediate  period,  some  functions  may  not  be  implemented 
within  a  given  ISDN.  Also  specific  arrangements  should  be  used  in  order  to  ensure 
compatibility  with  existing  networks  and  services.  These  features  and  arrangements  are 
specified  within  section  5  (part  III)  of  the  I-series  of  Recommendations.  ISDN  should 
also  give  access  to  existing  services  and  interwork  with  existing  networks  and  terminals; 
in  some  countries  this  situation  is  likely  to  exist  even  in  a  very  long  term. 

The  use  of  the  different  concepts  introduced  above  in  the  construction  of 
a  network  connection  type  is  shown  in  Figure  5. 
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1)  Each  node  X,  Y  or  Z  contains  two  network  functional  entities  and  a  protocol 
breakpoint . 

2)  Protocols  associated  can  be  in-band  or  out-band  (see  Recommendation  1.311). 


3)  The  CE  used  here  is  a  pure  functional  concept.  The  relationship  between  the 
concepts  used  in  I.3xx  (to  be  introduced  in  I.3xx)  needs  further  study. 


5.  High  layer  functions 


5.1  Classification 


The  same  principles  can  be  applied  in  the  case  where  higher  layer  functions 
are  involved  -  i.e.,  in  relation  with  telecommunication  services. 


The  translation  of  the  principles  described  in  section  3  leads  to  the  concept 
of  reap,  telecommunication  functions  and  additional  high  layer  functions. 


These  high  layer  functions  are  implemented  in  specialized  dedicated  service 
entities  and  in  the  terminals. 


The  specialized  dedicated  service  entities  can  be  centralized  in  special 
nodss  or  distributed  for  examples  in  switching  nodes. 


5.2  Application  connection 


Application  connections  are  supported  by  network  connections  and  cannot  be 
associated  to  a  unique  connection  element. 


In  the  simplest  case  a  unique  network  connection  support  the  application 
connection  (telecommunication  service  between  two  terminals). 
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FIGURE  6 


Application  connection  in  the  case  of  a  telec  uii cation  service 
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In  more  complex  sitvations  (Special  Node)  several  network  connections  are  used 
to  support  an  application  connection.  It  is  assumed  that  an  application  connection 
element  is  associated  to  each  network  connection  as  they  can  be  associated  to  high  level 
protocol  breakpoint. 

Figure  7  shows  an  example  of  a  possible  association  of  two  application 
connection  el-aments  in  a  unique  application  connection. 
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3P  :  Special  Node  (e.g.  Interworking  unit  using  level  7  functions) 

FIGURE  7 

Application  connection  elements 
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ISDN  PROTOCOL  REFERENCE  MODEL 

1.  Introduction 
1-1  General 

The  objective  ot  the  ISON  protocol  reterence  model  is  to  model 
inter  m  a  t  i  o  n  1 1  o  w  s,  i  n  c  1  u  d  l  n  9  use  r  i  n  t  o  r  m  a  t  i  o  n  a  n  d  c  o  n  t  r  o  1  i  n  t  o  r  m  a  t  i  o  n 
Flows, to  and  through  an  ISON.  It  is  based  on  the  principles  given 
in  the  X.200  series  ot  Recommendations. 

It  is  not  intended  as  a  det  i  n  i  t  i  on  ot  any  spec  i  t  i  c  l  r»p  1  enter  tat  i  on 
ot  an  ISON  or  ot  any  systems  or  e=tu  l  pment  i  n  ?  or  connected  to  >  an 
ISON. 

Examples  ot  applications  ot  this  model  are  included  in  this 
Recommendation. 


w. 


-  two  I b 0 N  users; 


an  ISDN  user  and  a  -functional  entity  within  an  ISDN, 


e-9-  network  control  -facilities* 


-  an  ISDN  user  and  a  functional  entity  inside  or  outside 


an  I  S 0 N  ?  e .  9 .  an  information  s t o r a 9 e / p r o c e s s  i  n 9 / m e s s a 9 1  ri 9 


f ac i 1 l ty ; 


various  functional  entities  in  an  ISDN* 


-  an  ISDN  and  other  networks. 


1*4  Relation  with  Recommendation  X-200 


The  protocol  reference  model?  interface  structures  and  protocol 


reference  conf i 9urat i ons  are  defined  by  layered  structures  based  on 


and  usin9  the  terminology  of  the  Reference  Model  for  Open  Systems 


Interconnection  <0SI)  for  CCITT  Applications  (draft  Recommendation 


X . 200  (Revised)).  The  layer  identification  used  in  Recommendation 


X.200  is  limited  in  this  Recommendation  to  the  use  of  layer  numbers- 


Layer  titles  (e9  network  layer)  as  used  in  Recommendation  X-200  are 


sometimes  misleading  in  the  ISDN  context?  and  have  not  been  used  here- 


Some  of  the  information  flows  descibed  above  are  considered  to  be 


outside  the  current  scope  of  Recommendation  X-200  (A  below)?  or  have 


not  yet  been  explicitly  modelled  by  Recommendation  X-200  <B  below). 


Examples  of  A  include; 


*  Information  flows  for  out-of-band  call  control  process?  or 


more  generally?  information  flows  among  multiple  related 


protocols? 


*  information  flows  for  selection  of  connection  characteristics? 


*  information  flows  for  renegotiation  of  connection  character¬ 


istics  for  calls; 


•*  information  flows  for  suspension  of  connections? 


*  information  flows  for  overlap  sending; 


*  in  general?  information  flows  for  multi -media  calls- 
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Examples  of  B  include: 

*  application  to  other  than  end-systems,  e.g.  signal  transfer  points 
(STPs)  and  inter-networking  points: 

*  information  flows  for  multi-point  connections; 

*  information  flows  not  included  in  X.200  considerations  such  as: 

-  voices  ( including  A/U  law  conversions) 

-  video 

-  transparent 

-  telex. 

One  objective  of  this  Recommendation  includes  an  examination  and  resolution  of 
these  issues.  Depending  on  the  resolution,  it  is  a  matter  for  further  study 
whether  the  ISDN  Protocol  reference  model  remains  a  separate  Recommendation  or 
whether  the  concepts  contained  in  this  Recommendation  should  be  incorporated 
in  a  redraft  of  the  X.200  series  of  Recommendations. 

1.5  Relation  with  the  Q-series  of  Recommendations 

The  functions  and  procedures  described  in  the  Q-series  of  recommendations 
for  access  and  network  signalling  in  general  conform  to  the  principles 
described  in  this  Recommendation.  Certain  features,  however,  in  particular 
facility  procedures,  user-user  signalling,  may  require  further  study  to 
determine  the  most  appropriate  method  of  modelling. 

2.  Modelling  Concepts 

2.1  Information  Flows 

The  information  flows  described  in  section  1.3  can  be  classified  into 
the  two  following  categories: 

1)  user  information  -  for  example,  digitized  voice,  data  and  other 
information  transmitted  between  users.  This  information  may 
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*  N  1  n -format  1  on  systems  -  rep  r  e  s  e  n  t  9  e  n  e  r  1  c  a  1  1  y  all  1  o  c  a  1 
( e . 9 .  terminal >  management  aspects  associated  with  the 
o -f  use r  into r  m a  t  i  o n  a n d  cant r o  1  i  n t o r m ation-  E x a m pies 

functions  include  the  selection  of  appropriate  responses 
connection  failure  and  other  exception  conditions  occur 
over  the  communication  facility.  These  functions  also 
"network  management"  and  traffic  control  to  optimize  ut 
ation  of  network  resources. 

3 .  External  interactions  of  a  protocol  block 

External  interactions  at  the  lower  and  upper  faces  of  a 
protocol  block  are  illustrated  in  Figure  2s 

-  Physical  transfer  of  information  (whether  transport 
or  control)  between  one  protocol  block  and  another 

takes  place  over  the  physical  media  attached  to 

U 

both  and  C  information  systems-  In  some 

V 

applications  (e.g..  ISDN  basic  access>>  a  common 

\J 

physical  medium  may  be  shared  by  both  ^  and  C 
systems- 

-  Interactions  at  the  upper  face  of  the  protocol 
block  to  various  application  processes 
external  to  the  block.  These  include  applications 
control  appl ications. etc. 

The  details  of  these  external  interactions  are  not  part 
of  the  ISON  protocol  refernce  model-  They  may  however 
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be  the  subject  of  other  CCITT  Recommendat i ons 
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4.  Inter-face  protocol  structures 

Protocols  and  procedures  used  at  the  boundary  of  an  ISDN  or  across 
an  interface  within  an  ISDN  are  described  in  terms  of  a  seuen- layer- 
structure  based  on  Recommendation  X . 200 •  As  described  in  section  2 • 1 
the  ISDN  network  architecture  is  such  that  generally  there  are  two 
planes  of  commun  l  cat  i  on  between  common  i  cat  i  ng  entities.-  name  1  y : 

-  the  user-  transport  plane  (or  U  Plane'1  accomodating  user  transport 
i nf ormat ion : 

-  the  control  plane  (or  C  plane)  accomodating  control  information- 
The  dialogue  in  each  plane  is  independently  described  in  terms  of  a. 
separate  seven  layer  structure,  corresponding  to  the  structure  of  the 

U  protocol  block  and  C  protocol  block  described  in  §2. 

In  some  applications-  some  of  the  layers  in  either  protocol 
structure  may  be  null-  and  some  layer  boundaries  may  be  considered 
to  exist  only  conceptual  1 y-  with  no  boundary  functions  (primitives) 
defined.  Layers-  layer  services  and  layer  protocols  will  be  defined 
only  when  necessary. 

The  seven  layers  of  the  protocol  structures  represent  seven 
distinct  ordered  partitions-  Each  layer  exhibits  specific  prop¬ 
erties  and  features  in  respect  of  their  relationship  both  with  adjacent 
layers  and  with  more  general  aspects  of  communications.  Each  layer 

offers  a  specific  layer  service  or  set  of  layer  services  to  the  layer 
above-  The  functions  of  each  layer  and  the  service  provided  by  each 
layer  are  defined  in  general  terms  in  Recommendation  X.200.  Detailed 
specification  of  layer  services  and  protocols  are  the  subject  of  other 
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ISDN  PROTOCOL  REFERENCE  MODEL 


From  the  fundamental  modelling  concepts  described  in  Section  2,  an 
ISDN  Protocol  Reference  Model  has  been  developed  as  illustrated  in  Figure  3. 
From  the  standpoint  of  modelling  the  various  network  elements  such  as  network 
control  facilities,  information  processing/messaging  facilities  as  shown  in 
Figure  1  can  be  treated  in  the  same  manner  as  a  user  system  such  as  a  terminal 
equipment  (TE). 


The  access  between  the  customer  equipment  and  the  network  is  represented  by 
the  S/T  reference  plane  (cf.  S/T  reference  point  in  the  ISDN  user/Network 
Reference  Configuration  as  described  in  Draft  Rec.  1.411. 


For  network  elements  such  as  exchanges,  signalling  points  (SP), 
signalling  transfer  points  (STP),  a  mirror  image  version  of  the  fundamental 
building  block  is  used.  This  representation  allows  peer-to-peer  protocols 
inside  the  network  as  well  as  ISDN  User/Network  access  to  be  taken  into 
account.  Note  however,  for  clarity  these  peer-to-peer  protocols  are  not  shown 
in  Figure  3. 


EXAMPLES  OF  APPLICATIONS  OF  THE  ISDN  PROTOCOL  REFERENCE  MODEL 


From  the  fundamental  modelling  concepts  described  in  section  2,  ISDN 
Protocol  configurations  have  been  developed  using  the  generic  protocol 
reference  model  described  in  section  5.  From  the  viewpoint  of  modelling  the 
various  network  elements  (such  as  network  control  facilities,  network  data 
bases,  information  processing/messaging  facilities)  can  be  treated  in  the  same 
manner  as  an  end  system  such  as  a  terminal  equipment  (TE). 


Figures  4  to  12  illustrate  applications  of  the  protocol  reference 
model  to  various  ISDN  connections. 


EXAMPLES  OF  APPLICATIONS  OF  THE  PROTOCOL  REFERENCE  MODEL  TO  NETWORK 
FUNCTIONAL  ENTITIES 


Figure  13  illustrates  a  model  representing  information  flows  and  associated 
logical  blocks  for  the  communication  process  in  terminal  equipment  (TE). 


For  network  elements  such  as  exchanges,  signalling  points  (SP), 
signalling  transfer  points  (STP),  a  mirror  image  version  of  the  protocol 
modellling  block  is  used.  This  representation  allows  peer-to-peer  protocols 
inside  the  network  as  well  as  ISDN  user  access  to  be  taken  into  account.  An 
example  of  such  a  model  is  shown  in  Figure  14. 
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Table  1  shows  four  different  types  and  their  functions. 

TABLE  1 


S-plane  information  categories  O) 

Note:  A  particular  application  may  use  any  combination  of  S-j,  S2  and  S3. 


TYPE 

FUNCTION 

APPLICATIONS 

ILLUSTRATION 

Si 

User-to-network 
in-band  signalling 

Establishment,  flow  control 
and  clear  down  of  S  infor¬ 
mation  type  at  layer  3 

Figure  7 

S2 

User-to-network 
common  channel 
signalling 

-  Call  set  up  and  release 
of  B-channel 

-  Other  uses  are  for 
further  study  (e.g.  call 
set-up  for  P-type  of 
information  in  multimedia 
calls) 

Figure  6 

S3 

User-to-user 

signalling 

53A 

-  TE  to  TE  signalling 

-  PABX  to  PABX  signalling 

Figure  8 

S38 

-  TE  to  HLF(2)signalling 

-  TE  to  network  data  base 
signalling 

L_ 

S4 

- - - 

User-to-operations 
centre  signalling 

-  TE  to  local  exchange 
signalling  for  operation 
and  maintenance  (Note  3) 

Figure  9 
(Note  3) 

Note  T:  Internal  network  signalling  and  its  relationship  to  above  categories 
i s  not  dealt  with  in  this  Recommendation. 

Note  Z:  HIF  may  reside  inside  or  outside  the  network. 


Note  3:  Figure  9  shows  the  operations  centre  reached  via  the  local  exchange. 
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Figured  -  External  interactions  associated  with  a 
fundamental  building  block 
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Reference  Plane 


Reference  Plane 
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Network 


(Note  2) 


(Note  2) 


Note  1 : 


Within  the  network,  different 
physical  media  connections  may  be  used 
between  fundamental  building  blocks  (e.g. 
exchanges.  Signalling  Points,  Signalling 
Transfer  Points.) 


Note  2 :  For  network  elements  that  perform  relaying  functions 
(such  as  suitching  exchanges,  signalling  transfer 
points) ,  the  U  information  functional  grouping  is 
represented  by  the  lower  three  layers  only.  For  net¬ 
work  elements  that  perform  end-systems  functions  (such 
as  those  providing  information  processing/messaging 
facilities),  all  the  seven  layers  are  represented. 


Figure  J*-  ISDN  protocol  reference  model 
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Figure  If a-  ISDN  protocol  reference  configuration  for 
circuit-switched  connection  ( three-layer 
approach  used) 
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Figure  %  -  ISDN  protocol  reference  configuration 
for  packet-switched  connection  via 
D  channel  (three-layer  approach  used) 


bb 

Figure  %  -  Application  to  packet  switched  connection 

via  D- channel  in  the  ISDN  (illustration  of  S^) 


ISDN  protocol  reference  configuration  (basic 
connection  -  P/S  via  B  channel)  for  packet- 
avitched  connection  via  B  channel  (three-layer 
structure  used) . 


Access  P/S  facility  Information 

to  P/S  processing 

facility 


Figure  -  ISDN  protocol  reference  configuration 
(access  to  HLF  -  P/S  via  B  channel) 
for  packet-switched  access  to  higher 
layer  functions  via  B  channel  (three- 
layer  structure  used) 


0  channel  handler 
and  P/S  facility 


Information  pro-  \| 
ceasing  facility  ccitt-*mj» 


N 


Figure  ^  -  ISDN  protocol  reference  configuration 
for  packet-switched  access  to  higher 
layer  functions  via  D  channel  (three- 
layer  approach  used) 
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Question  :  1/XVIII,  paragraph  B 


SOURCE 


AD  HOC  GROUP  IN  WORKING  TEAM  3 


TITLE  :  COMMENTS  ON  DRAFT  REC.  I.3XX  (PROPOSED  1.325) 
AS  GIVEN  IN  TD  30 


DFAFT  OF  I.3XX  -  ISDN  CONNECTION  TYPES 


The  results  of  the  Drafting  Group  set  up  in  Plenary  to  review 
I.3XX  is  contained  in  TD  30. 


Subsequent  to  the  issue  of  TD  30  a  major  contribution  was  received 
from  a  delegation  who  had  been  unable  to  attend  the  meeting  of  the  Drafting  Groui 


Meanwhile,  the  chairman  of  the  Drafting  Group  (Mr.  Valdar  -  BT) 
had  returned  home,  as  had  several  other  members  of  the  Drafting  Group. 


In  an  attempt  to  assess  the  new  contribution,  and  to  ease 
discussions  in  Plenary,  it  was  decided  to  establish  an  Ad  Hoc  Group  to 
incorporate  these  comments  in  draft  Rec.  I . 3XX  for  consideration  in  Plenary. 
The  results  of  this  Ad  Hoc  Group  are  attached. 


It  is  stressed  that  this  temporary  document  does  not  reflect 
the  views  of  the  original  Drafting  Group,  though  several  members 
of  that  group  participated  in  the  ad  hoc  Group. 
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ISDN  CONNECTION  TYPES 


The  CCITT, 


considering 


-  that  the  ISDN  concept  is  described  in  Recommendation  1.120; 


-  that  services  provided  by  the  ISDN  are  described  in  draft  Recommendation  1.200; 


-  that  the  ISDN  functional  architectural  model  is  described  in  draft 
Recommendation  1.310.  That  Recommendation  describes  and  defines  functional  elements 
in  the  ISDN.  It  also  provides  a  functional  architectural  model  which  forms  the  basis 
of  the  definition  of  reference  configurations  in  this  Recommendation; 


-  that  the  ISDN  protocol  reference  model  is  described  in  draft 
Recommendation  1.311; 
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unanimously  declares  the  view 

that  the  ISDN  can  be  described  by  a  limited  set  of  ISDN  Connection  types 
to  support  ISDN  services.  This  Recommendation  defines  and  identifies  these  Connection 
types  and  their  application.  They  should  form  the  basis  for  other  Recommendations 
on  such  matters  as  Network  Performance,  etc. 

Note  -  As  the  ISDN  concept  evolves  other  Connection  types  may  be  identified. 

\£>0  tJ 

1.  Basic  concept  of  Ha4werk  Connection  types  in  an  ISDN 

1  ■  1  Pn  i-poag  a  @  IS  P  Kl  c  o\->na-c.U  an 

An  ISDN  provides  a  set  of  network  capabilities  which  enable  bearer  and 
telecommunication  services  to  be  offered  to  a  user  (refer  to  draft  Recommendation  1.200). 
The  ISDN  lower  layer  capabilities  (refer  to  draft  Recommendation  1.310)  may  be 
described  by  a  limited  set  of  Connection  types  which  together  with  additional  (lower 
and/or  higher  layer)  network  functions,  where  appropriate,  will  support  the  range  of 
telecommunications  and  bearer  services.  The  relationship  between  network  connections 
and  services  is  shown  in  Figure  1. 


The  purpose  of  identifying  a  set  of  ISDN  Connection  types  is  to  assist 
in  the  specification  of  such  parameters  as  network-to-network  interfaces  and  allocation 
of  network  performance.  The  relationship  between  the  service  requested  and  the 
Connection  type  provided  is  covered  in  section  .  (It  should  be  noted  that  subs¬ 

cribers  will  not  be  able  to  selected  a  particular  Connection  type.) 

Service  OffWrlnm  Network  CmhlUtr 


Bearer  Service 


Limited  set  of  ISDN 

1 

i 

Connection 

i  . 

Connection  type* 

Elements 

j- 

Telecoam*.  Service 

!  Additional  network  fraction* 1 

(Note  1) 

vtiere  required  to  support  J 
the  eervlce  w.g.  additional  J 
lower  layer  function*,  I 
higher  layer  function*.  I 

I 

I 

I 

_ J 

eon -urn 


FIGURE  1 

Relationship  between  an  ISDN  service  offering 
and  its  network  capability 

See  section  for  an  explanation  of  Connection  Elements. 

It  should  be  noted  that  the  terms  ISDN  Connection  type  and  ISDN  Connection 
have  a  specific  meaning  in  the  context  of  this  Recommendation. 

An  ISDN  Connection  type  is  a  description  of  a  form  of  connection.  A 
particular  example  of  this  type  is  an  individual  network  connection,  "so  an  ISDN 
Connection  is  an  instance  of  an  ISDN  Connection  type". 
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An  ISDN  Connection  is  an  association  of  functions  to  support  Bearer  and 
Telecommunication  Services  as  shown  in  Figure  2.  Three  sets  of  functions  are  required  : 

i)  Connection  means  -  including  transmission,  switching  and  routing  functions; 

ii)  Control  functions  and  protocols  -  including  signalling,  flow/congestion 
control; 

iii)  Operational  functions  -  including  network  management  and  maintenance. 


FIGURE  2 

l  3  .^  [°  j°'  ■'e  oA-'on 

ISDN  Connection  types  can  apply  to  three  situations  which  have  so  far  been 
identified  (others  may  exist)  ; 

-  between  two  user-network  interfaces,  i.e.  between  S/T  reference  points 
(Figure  3a); 

-  between  a  user-network  interface  and  a  network-network  interface  to  be 
defined  in  Recommendation  1.500  (Figure  3b)  (for  further  study); 

between  a  user-network  interface  and  a  network  resource  (Figure  3c). 

Note  -  Network  Resource 

Within  the  context  of  this  Recommendation  the  term  network  resource  is 
intended  to  mean  any  entity  within  the  network  which  is  accessible  by  an  ISDN 
connection  for  the  purpose  of  providing  a  service  at  the  S/T  interface  (Figure  3c), 
or  for  fulfilling  network  functions.  Use  of  a  network  resource  originates  from  a 
user  service  request  or  for  internal  administration  purposes.  Some  examples  are  : 

1)  a  network  node  incorporating  ALLF  and/or  HLF; 

2)  a  network  provided  data  base; 
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l.U  Attributes  of  an  ISDN  connection  type 


ISDN  connection  types  are  characterised  by  the  attributes  shown 
in  figure  6. 

The  limited  set  of  ISDN  connection  types  is  given  in  Table  1. 


Ay  />«-» 

The  attributes  which  define Vfconnection  .  clcmente  (partieui-arily 
thoae-for  the  looal  connection  eleaen»)  have  a  similarity  to 
those  used  to  define  Bearer  Services  in  draft  Recommendation 
However  the  two  sets  of  attributes  differ  in  several 
important  aspects. 

(i)  ISDN  Connections  represent  the  technical  capabilities 
of  the  Network  and  are  a  means  to  standardize  inter¬ 
connection  of  ISDNs. _  Bearer  Services 

(and  other  services  defined  in  1. 20ft)  are  the  packages 
offered  to  customers  and  standardisation  of  their 
attributes  is  the  means  to  standardising  the  service 
offerings  world-wide. 

(ii)  A  second  major  difference  is  that  operational  and 

commercial  attributes  are  relevant  to  bearer  services, 
whereas  operations  and  maintenance  attributes  are 
relevant  to  connection  types. 
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ISDN  Connection  types  may  be  considered  to  be  composed  of  Connection 
Elements,  each  described  by  a  set  of  attributes.  This  concept  is  illustrated  in 
Figure  4,  which  could  represent  an  example  of  64  kbit/s  circuit  switched  network 
connection  in  a  national  ISDN  in  which  Connection  Elements  1  and  3  represent  the 
access  portion  and  Connection  Element  2  represents  the  National  transit  portion  of 
the  connection. 
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Example  of  Connection  Elements  forming 

an  ISDN  Connection  type  III 
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Some  iSUN  Connection  types  may  be  formed  from  a  number  of  Connection 
Elements  which  are  contained  in  separate  networks.  These  separate  networks  may  or 
may  not  be  ISDNs,  but  in  either  case  they  support  the  attributes  of  the  ISDN 
Connection  type.  Inter-network  Interfaces  exist  between  each  network.  This  is 
shown  in  Figure  5. 


FIGURE  5 

Example  of  Connection  Elements  forming  an  ISDN  Connection  type 
Involving  several  networks 
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Possible  attributes  for  Connection  pe-3  and  conn c eU’»o  eJ« 

*  Provisional  definitions  of  the  values  of  these  attributes  are  given  in  Appendix  1 
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Association  rules  for  attributes  of  ISDN  connection  element 


Connection  elements  are  also  defined  by  a  set  of  attributes 
(see  figure  6).  Some  of  these  attributes  are  of  a  general  or  dominating  nature 
leading  to  a  limited  set  of  ISDN  connection  types  as  described  in  section  l.lt. 

This  limited  set  of  connection  types  will  have  the  capability  to  support  the 
Bearer  Services  defined  in  draft  Rec.  1,200  but  they  are  not  intended  to  limit 
the  ways  by  which  a  network  provider  implements  those  services,  This  is  because 
within  a  set  of  connection  elements  comprising  a  connection  type,  other  attributes 
can  vary  to  produce  various  connection  types  all  of  which  may  be  suitable  to 
support  a  particular  Bearer  Service.  It  should  be  noted  that  the  structure  of 
fig.  6  does  not  imply  that  all  possible  combinations  of  attributes  will  lead  to 
standardized  or  even  useful  examples  of  connection  elements. 

The  above  considerations  lead  to  a  series  of  association  rules 
by  which  the  attributes  of  individual  connection  elements  determine  the  attributes 
for  a  connection  type.  For  example, 

i)  if  any  one  or  more  connection  elements  involves  a  packet  attribute, 
then  the  attributes  of  the  connection  type  is  packet 

ii)  if  any  one  or  more  connection  elements  involves  a  non-transparent 
attribute,  then  the  attribute  of  the  connection  type  is  non-transparent 

iii)  if  one  connection  element  has  the  lowest  channel  capability,  then 
the  channel  capability  attribute  of  the  connection  type  has  the  channel  capability 
of  that  connection  element. 

An  example  of  the  way  the  attributes  of  connection  elements  determine 
the  attributes  of  the  connection  type  is  shown  in  fig.  7»  which  shows  a  set  of 
connection  elements  making  up  a  connection  type  for  a  packet  call  over  a  B  channel. 
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3 .  Relationship  between  ISDN  Connection  types  and  Connection  Elements 

Section  1  introduced  the  concept  of  subdividing  an  ISDN  Connection  type 
into  Connection  Elements  which  are  characterized  by  a  set  of  attributes. 

In  general  Connection  Elements  may  be  combined  in  space  or  in  time,  or  both, 
to  form  Connections. 

There  are  three  general  categories  of  Connection  Elements  (CEs)  : 

i)  Local  Connection  Elements.  This  is  the  part  of  the  ISDN  Connection  type 
from  the  S  or  T  reference  point  to  the  output  side  of  the  Local  Connection 
related  function.  Examples  are  given  in  Figure  10. 


ii)  Transit  Connection  Elements.  This  is  the  part  of  the  ISDN  Connection 

which  in  the  case  of  : 

a)  a  National  Call  is  between  the  two  Local  Connection  Elements; 

b)  an  International  Call  is  between  the  end  of  the  Local  Connection 
Element  and  the  output  of  the  International  Switching  Centre; 

c)  an  international  call  between  the  end  of  the  two  National  Connection 
Elements . 

3.1  This  section  presents  a  framework  and  terminology  for  des¬ 
cribing  the  configuration  of  ISDN  Connection  types  which  con¬ 
sists  of  multiple  Connection  Elements.  Such  configurations  can 
be  described  by  four  attributes:  topology,  uniformity,  dynamics 
and  Connection  Elements  involved  (figure  8). 

Topology  refers  to  the  way  that  Connection  Elements  are 
arranged  to  form  the  ISDN  Connection.  Example  topologies  are: 
point-to-point,  tandem,  parallel,  hub  and  combinations  of  these 
topologies  (figure  8a)). 

Uniformity  refers  to  the  attributes  of  the  individual 
Connection  Elements  (figure  gb)).  When  all  of  the  Connection 
Elements  in  a  configuration  have  the  same  attributes,  the  con¬ 
figuration  is  described  as  uniform.  When  the  Connection  Elements 
are  different,  the  configuration  is  described  as  non-uniform. 

Dynamics  refer  to  the  way  the  Connection  Elements  are 
established  in  time  (figure  8c)).  When  all  of  the  Connection 
Elements  are  established  simultaneously  and  released  simultaneously, 
the  configuration  is  described  as  concurrent.  When  the  Connection 
Elements  are  established  and  released  sequentially  (i.e.  only  one 
Connection  Element  chain  exists  at  any  given  time)  the  con¬ 

figuration  is  described  as  sequential.  When  Connection  Elements  can 
be  established  or  released  while  other  Connection  Elements  exist, 
the  configuration  is  described  as  add/remove. 
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Topology 


1)  Point-to-point;  simple 


ii)  Point-to-point;  tandem 
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lii)  Point-to-point;  parallel 


lv)  Point-to-multipoint;  hub 


▼  )  Others  (for  further  study) 


Uniformity 


i)  Uniform  (All  Connection  Elements  identical) 


ii)  Non-uniform  (Some  Connection  Elements  different) 


Dynamics 


i)  Concurrent  (All  Connection  Elements  established  and  released  simultaneously) 


ii)  Sequential  (Only  one  Connection  Element  established  at  a  given  time) 


iii)  Add/remove  (Connection  Elements  may  be  added  and/or  removed  during  a  call) 


Figure  8  -  Description  of  Connection  .cr.figuratic 
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The  dynamics  of  an  ISDN  Connection  type  do  not  have  to  be  identical  to  the 
dynamics  of  the  service(s)  it  supports.  For  example,  a  service  which  allows  a  customer 
to  alternately  send  voice  or  data  (i.e.  a  sequential  service)  could  be  supported  by 
a  concurrent  connection  for  which  only  one  of  the  Connection  Elements  is  made  available 
to  the  customer  at  any  given  time.  Alternatively,  a  single  Network  Connection  type 
could  be  defined  which  could  have  one  of  its  attributes  modified  during  a  call 
(e.g.  switching  in  and  out  of  A/Mu  law  converters). 

.  Relationship  between  services  and  ISDN  Connection  types 


This  relationship  can  be  described  by  taking  account  the  communication 
capabilities  associated  with  Bearer  and  Telecommunications  services.  A  "Communication 
Capability"  is  defined  as  a  set  of  rules  characterizing  the  use  made  within  the  network 
of  the  different  ISDN  Connection  types.  The  Communication  capability  is  based  on 
three  groups  of  ISDN  Connection  types,  (CT)  : 

i)  Preferred  ISDN  Connection  type  group 

A  Communication  capability  is  based  on  the  use  of  any  ISDN  CT  in  the  group. 
However,  one  ISDN  CT  is  preferred,  for  example  : 

For  the  telephony  service,  the  Communication  capability  is  based  on  either  a 
Non-transparent  64  kbit/s  connection  (preferred),  or  a  transparent  64  kbit/s 
connection.  (A  particular  case  is  a  1-1  association  of  Bearer  service  to  Connection 
type.) 

ii)  Al-temative  group 

During  a  service  communication,  the  Communication  capability  is  based  on  the 
alternative  use  of  different  ISDN  CTs,  for  example  : 

Universal  service  -  change  of  ISDN  CT  during  a  call  (the  corresponding 
attributes  are  not  the  dominant  attributes ) . 

iii)  Simultaneous  group 

The  Communication  capability  is  based  on  the  use  of  several  ISDN  TCs 
simultaneously,  for  example,  multi-media  services. 

5.  Reference  configurations 

Based  on  the  concepts  which  define  the  functionality  of  ISDN 
connections  in  draft  Rec  1.310,  figure  9  below  shows  the  general 
concept  of  ISDN  Connection  type. 
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ISDN  Connection  type 


I  international 
National  Transit  Connection  Uesert 


Local  Connection  Cieaent 


Fig  9;  General  Concept  of  ISDN  Connection  Type  and 
Connection  Elements 


V 

»■ 


v\-VVv  •.  v\- >>>. 


As  defined  in  draft  Rec  I. 310  the  Connection  Related  Function  (CRF) 
includes  functions  such  as  exchange  terminations  switching,  control 
network  management,  operations  and  maintenance.  So  in  the  case  of 
the  local  CRF  it  is  the  point  where  the  level  1  functions  are 
switched  and  the  level  3  protocols  terminate.  Similarily  the  National 
CRF  represents  the  functional  units  involved  in  switching  in  the 
national  network  (which  could  involve  several  switching  centres)  and 
the  International  CRF  represents  the  functional  units  involved  in 
switching  in  the  international  network.  The  links  between  these  CRFs 
represent  transmission  systems. 

Examples  of  local  Connection  Elements  for  (a)  64  kbit/s  circuit 
switched  transparent  and  (b)  packet  switched  virtual  circuit  in 
D  channel  are  shown  in  fig  10. 


Exchange  Connection  6*  kbit/s  circuit-switched  transparent 
(as  defined  by  SG  Xl/h) 


Local  Connection  tleaent 

kbit/s  circuit-switched  transparent 

Note:  The  inclusion  of  a  remote  multiplexer  and/or  a  remote 

system  independent  switching  unit  are  possible  options  for 
network  providers. 


Figio(a):  Reference  Configuration  for  64  kbit/s  circuit- switched 
transparent  local  connection  Element 
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Local  Connection  Element 

P.S.  Virtual  Circuit  in  D  channel 
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Alternative  (1) 


Local  Connection  Eleaent 

P.S.  Virtual  Circuit  in  D  channel 


FiglO  (b)  Reference  Configuration  for  Packet  Switched 

Virtual  Circuit  in  D  Channel  Local  Connection 
Element 
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Appendix  1 


(to  draft  Recommendation  I.3xx) 


Definitions  of  different  values  of 


Attribute  :  "Establishment  of  Connection" 


Three  categories  have  been  proposed  : 


They  are  set  up  on  demand  at  any  time. 


They  are  set  up  and  cleared  down  in  response  to  subscriber  control 
procedures. 


""he  duration  of  the  connection  is  unspecified. 


Reserved 


They  are  set  up  following  subscriber  application, either  by  operator 
action^or  in  response  to  subscriber  signalling  control  procedures. 

"■hev  are  cleared  further  action  after  subscription  . 


They  are  set  up  for  a  fixed  period  of  time,  or  for  an  agreed  period 
during  e  daV^week^r  other  interval. 


Permanent 


They  are  set  up^following  subscriber  application  either  by  operator 
action^or  in  response  to  subscriber  control  procedures. 


Only  the  starting  time  is  given  at  the  time  of  application.  Clear 
down  requires  another  inter-action. 


They  are  set  up  for  an  indefinite  period. 


Attribute  :  "Transparency" 


For  further  study. 
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1. 


General 


1.1  Introduction  (to  be  drafted) 

1.2  Scope  and  field  of  application 

This  Recommendation  defines  the  layer  1  characteristics  of  the  user 
to  network  interface  to  be  applied  at  the  S  or  T  reference  points  for  the 
basic  channel  structure  defined  in  1.410. 

In  the  following,  NT  will  be  used  to  indicate  arrangements  of  NT1  and 
NT2  and  TE  will  be  used  to  indicate  TE1  or  TA  or  NT2,  unless  otherwise  stated. 

2.  Service  Characteristics 

2. 1  Services  required  from  the  Physical  Medium 

2.2  Services  Provided  to  Layer  2 

Layer  1  provides  the  following  services  to  Layer  2: 

2.2.1  Transmission  capability  by  means  of  appropriately  encoded  bitstreams, 
for  both  B  and  D  channels  and  also  any  related  timing  and  synchronization 
functions. 

2.2.2  The  signalling  capability  and  the  necessary  procedures  to  enable 
customers  terminals  and/or  network  terminating  equipment  to  be  deactivated 
(i.e.,  placed  in  a  low  power-consumption  mode)  when  required  and  reactivated 
when  required.  The  activation  and  deactivation  procedures  are  defined  in 
sections  6.2  and  6.3. 

2.2.3  The  signalling  capability  and  the  necessary  procedures  to  allow 
terminals  to  gain  access  to  the  common  resource  of  the  D  channel  in  an  orderly 
fashion  while  meeting  the  performance  requirements  of  the  D  channel  signalling 
system.  These  D  channel  access  control  procedures  are  defined  in  section  6.1. 

2.2.4  The  signalling  capability  and  procedures  and  necessary  functions  at 
layer  1  to  enable  the  general  maintenace  principles  defined  in  Recommendations 
Q.950  to  be  implemented  as  required. 

2.2.5  An  indication  to  the  higher  layers  of  the  status  of  layer  1  (e.g., 
activate  indication  or  deactivate  indication). 

2.3  Primitives  between  Layer  1  and  Layer  2 

To  facilitate  the  correct  interaction  between  Layer  1  and  higher 
layers,  the  primitives  to  be  passed  across  the  layer  1/2  boundary  are  defined 
and  summarized  in  Table  1.1.431.  The  parameter  values  associated  with  these 
primitives  are  summarized  in  Table  2/1.431.  For  a  description  of  the  syntax 
and  use  of  the  primitives,  refer  to  Recommendation  X.211  and  relevant  detailed 
descriptions  in  section  6  of  this  Recommendation.  Table  3/1.431  defines  the 
primitives  passed  between  Layer  1  and  Layer  2  (or  the  Management  entity). 
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TABLE  1/1.431 

Primitives  between  layers  1  and  2 


PRIMITIVE  | 

GENERIC 

NAME  1  REQUEST  INDICATION  RESPONSE  CONFIRM 


Data  I  X  X 

Activate  X  X 

Deactivate  X  X 


TABLE  2/1.431 
Primitive  Parameters 


PRIMITIVE 

GENERIC 

NAME 


PRIORITY  MESSAGE 
INDICATOR  UNIT 


WJUAH  W.  LWW.  k1  i*  i.1  v1  J ~ 

!£ 


rr*  *  *  .  *  *3 9  • '  «. '  ■. 1 


"1  w  7  W-  .  ^  ^  ■« 


r  v  »,  a 


>  .V. 

yy. 

>:•••  -Wv 
•■•■•.  -/• 


-  51  - 

COM  /.mi -tie.  K  iS- 


A.097 


3.  Modes  of  opera  lion 

Both  point-to-point  and  point-to-multipoint  ];.  .!o.;  ».f  operation,  described 
below,  arc  intended  t.o  he  accommodated  by  the  layer  .1  eh  .ructeristi os  of  the  inter¬ 
faces.  In  this  Recommendation,  the  ino.it -a  of  operation  apply  only  to  the  layer  1 
procedural  characteristics  o'1  ttie  interface  and  do  not  imply  any  constraints  on  nodes 
of  operation  at  higher  layers. 

1.1  i  oint-t.u-point 


Point-to-point  operation  at  layer  1  iapiie.,  that  only  one  source  ( trutnsmi  t.t.er ) 
and  one  sink  (receiver)  are  active  at  the  interface  at  any  one  time.  (Such  operation 
is  independent  of  the  number  of  interfaces  which  may  he  provided  on  a  particular 
wiring  configuration  -  see  section  4.) 

1 .  d  i'o  int- Ui-;:.nltir>oint 


Po Lut-to-i,iui ti point  operation  at  layer  L  allows  more  than  uw  terminal 
(source  i ho  sink  pair)  to  be  siiiriltuneously  active  at  at.  3  or  T  reference  point.  (The 
multipoint  mode  of  operation  may  be  accommodated,  as  discussed  in  section  4.  with 
point-to-point  or  point-to-multipoint  wiring  configurations.) 

4 .  Types  of  wiring  -onfi  para  ti  on 

In  order  to  determine  the  electrical  characteristics  of  the  Hser/Network 
interface,  it  is  necessary  to  make  certain  assumptions  about  the  various  wiring 
configurations  which  may  exist  within  the  users  premises.  These  assumptions  are 
identified  in  two  major  configuration  descriptions  below,  together  witii  additional 
material  contained  in  Annex  1  to  this  Recommendation.  Figure  1  shows  a  general 
Reference  Configuration. 

A  precise  location  of  the  User/Network  Interface(s)  is  also  necessary  for 
electrical  definition.  Figure  1/1.431  is  a  general  Reference  Configuration. 

4.1  Point-to-point 

Point-to-point  wiring  configuration  implies  that  only  one  source  (transmitter) 
and  one  sink  (receiver)  are  interconnected  on  an  interchange  circuit. 

4.2  Point-to-multipoint 

Point-to-multipoint  wiring  configuration  allows  more  than  one  source  to  be 
connected  to  the  same  sink  or  more  than  one  sink  to  be  connected  to  the  same  source 
with  an  interchange  circuit.  Such  distribution  systems  are  characterized  by  t.he 
fact  that  they  contain  no  active  logic  elements  performing  functions  (other  than 
possibly  amplification  or  regeneration  of  the  signal). 

4.3  Wiring  polarity  Integrity 

For  point-to-point  wiring  configuration  the  two  wires  of  the  interchange 
circuit  pair  may  be  reversed.  However,  for  point-to-multipoint  wiring  configuration, 
the  wiring  polarity  integrity  of  the  interchange  circuit  (TE  to  NT)  must  be  maintained 
between  TKs . 
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4.4  Location  of  the  interface 

The  wiring  in  the  user  premises  is  considered  to  be  one  continuous  cable 
run  with  sockets  for  the  TE  and  NT  equipment  attached  directly  to  the  cable  or  via 
stubs  <  1  metre  in  length. 

The  sockets  constitute  two  potential  interface  location  points.  One  inter¬ 
face  would  be  adjacent  to  each  TE  and  the  other  interface  would  be  adjacent  to  the 
NT.  It  is  desirable  for  these  interface  points  to  be  electrically  equivalent. 

4.5  NT  and  TE  associated  wiring 

The  wiring  from  the  NT  or  TE  equipment  to  its  appropriate  socket  can  affect 
the  interface  electrical  characteristics.  Thus  a  connecting  lead  of  not  more  than 
10  metres  and  a  suitable  plug  are  considered  to  form  part  of  the  NT  and  TE  equipment. 

5.  Functional  characteristics 

5.1  Interface  functions 


5.1.1 


B- channel 


This  function  provides  for  the  bi-directional  transmission  of  the  two 
independent  B-channels  each  having  a  bit  rate  of  64  kbit/s  as  defined  in  Recommenda¬ 
tion  1.432. 

5.1.2  Bit  timing 


This  function  provides  bit  (Signal  Element)  timing  at  192  kbit/s  to  enable 
the  terminal  or  NT2  to  recover  information  from  the  aggregate  bit  stream. 


5.1.3 


Octet  timing 


This  function  provides  8  kHz  octet  timing  towards  the  terminal  or  NT2, 
primarily,  for  the  purpose  of  enabling  correct  operation  of  PCM  voice  encoders  but 
which  may  be  used  for  other  purposes  as  required. 


5.1.4 


Frame  alignment 


This  function  provides  information  to  enable  the  terminal  or  NT2  to  recover 
the  time  division  multiplexed  channels. 


5.1.5 


D- channel 


This  function  provides  for  the  bi-directional  transmission  of  one  D-channel, 
as  defined  in  Recommendation  1.412  at  a  bit  rate  of  16  kbit/s. 


5.1.6 


D-channel  access  control 


This  function  is  specified  to  enable  terminals  to  gain  access  to  the  common 
resource  of  the  D-channel  in  an  orderly,  controlled  fashion.  The  functions  necessary 
for  these  procedures  include  an  echoed  D-channel  at  a  bit  rate  of  16  kbit/s  in  the 
direction  NT  to  TE  (or  NT2).  For  the  definition  of  the  procedures  relating  to  D-channel 
access  control  see  section  6.1. 


^  , •*'.  T.  ■  v 

.*  /  v*,«  .•*  .  •  .  V  ‘.N,  ,  •  .  «  .  .*•  ^  /.  %  ,*•  '• 

*»  V  */  *  •/  .y.  *  .  *  ,  »  ,  «*„  •  ,  *  .  • 

•**/'■*  * %v  V 
/  •  *.  V*  .N  -V  V-" \ 


'«  •>*  #1 


A. 099 


'.*■.*»* 

•-  v  - '  ' 


COM  XVI I I -No.  R  1B-E 


5.1.7 


lower  food 


This  function  provides  for  the  capability  to  transfer  power  across  the 
interface.  The  direction  of  power  transfer  depends  on  the  application.  In  a  typical 
application  it  may  bo  desirable  to  provide  for  power  transfer  from  the  network  side 
towards  tin;  terminals  in  order  to,  for  example,  maintain  a  basic  telephony  service 
in  tire  event  of  failure  of  the  locally  provided  power.  (In  some  applications 
undirootionul  power  feeding  or  no  power  feeding  at  all  access  the  interface  may  apply.) 
The  detailed  specification  of  power  feeding  capability  is  contained  in  section  o. 


5.1.H 


point  deactivation 


This  function  is  specified  in  order  to  permit  terminals  anu  NT  equipment 
to  be  placed  in  a  low  power  consumption  mode  when  no  calls  are  in  progress.  The 
procedures  and  precise  conditions  under  which  such  deactivation  taker,  place  are 
specified  in  section  6.3. 


point  activation 


This  function  allows  the  terminal  or  HT2  to  be  restored  to  its  normal 
operating  power  mode.  The  procedures  and  precise  conditions  under  which  such 
activation  takes  place  are  defined  in  section  6.2. 


Interchange  circuits 


Two  interchange  circuits,  one  for  each  direction  of  transmission,  shall  be 
used  to  transfer  digital  signals  across  the  interface.  All  of  the;  functions  described 
in  section  5.1,  except  for  power  feeding,  shall  be  carried  by  means  of  a  digitally 
multiplexed  signal  structured  as  defined  in  section  5.\. 


aration  indica 


The  TE  shall  dj/Cermine  the  following  conditions  : 


a)  disconnected; 


connected  to  a  point-to-point  wiring  configuration; 
cowiected  to  a  point-to-multipoin>/'wiring  configuration. 


The  TE  distinguishes  (see;  Note)  conditions  b)  or  <•)  from  a) 


the  presence  of  a  resistance  terininfrxing  the  leads  designated  1  and  2  in  VU 


srminal  distinguishes  (see  Ucto)  condition  t> )  from  condition  c )  h; 


the/value  of  the  resistance.  2he  resistance  is  determined  by  a  resistor  located  in 


the  jack  terminating  the  interconnecting  cable  and  connected  betw«*ff  the  appropriate; 
^ins.  The  different  resi^or  values  for  point-to-point  and  multipoint  wiring  con-  / 
figuration  is  for  further  study.  [ 


Note  :  Alternative  methods  for  distinguishing  these  conditions  should  be  studied. 
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5 . 3  Detection  disconnected  state 

The  detection  of  the  connected/disconnected  state  is  used  for 
initiating  the  TEI  assignment  procedures  and  the  activation/deactivation 
procedures . 

A  TE  shall  enter  the  connected  state  and  initiate  renegotiation 
of  its  TEI  when  it  is  powered  (or  repowered)  up  and/or  after  it  detects  the 
reappearance  of  input  framing  signals  (assuming  its  prior  detection  of  the 
cessation  of  such  signal).  As  an  alternative  to  initiating  such  renegotiation 
in  response  to  the  detection  of  the  reappearance  of  framing  signals,  a  TE, 
that  is  connected  to  an  interface  on  which  voltage  appears  in  the  phantom  mode 
(power  source  1  in  section  9.1),  may  enter  the  connected  state  and  initiate 
such  renegotiation  upon  the  detection  of  the  reappearance  of  the  phantom 
mode  voltage.  (This  latter  operation  is  preferred  where  voltage  is 
available  on  the  phantom). 

Note  :  Alternative  methods  for  detecting  this  state  should  be  studied. 
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5.4  Frame  structure 

In  both  directions  of  transmission,  data  shall  be  grouped  into  frames 
of  48  bits  each.  The  frame  structure  shall  be  identical  for  all 
configurations  (point-to-point  and  point-to-multipoint) .  All  bits  reserved 
for  future  standardization  shall  be  set  to  binary  "0". 

5.4.1  Bit  rate 

The  norminal  transmitted  bit  rate  at  the  interface  shall  be  192 
kbit/s  in  both  directions  of  transmission.  Each  48  bit  frame,  therefore,  has 
a  nominal  duration  of  250  microseconds.  The  precise  bit  rate  is  determined  by 
the  network  clock  frequency. 

5.4.2  Binary  organization  of  the  frame 

The  frame  structures  are  different  for  each  direction  of 
transmission.  Both  structures  are  illustrated  diagrammatically  in  Figure 
2/1.431. 

5.4.2. 1  Terminal  to  network 

Each  frame  consists  of  the  following  groups  of  bits;  each  individual 

group  is  DC -balanced  by  a  trailing  balance  bit  (L-bit)  : 


bit  position 

1  and  2 
3  -  11 

12  and  13 
14  and  15 
16  -  24 
25  and  26 
36  and  37 
38  -  46 
47  and  48 

5. 4. 2. 2  Network  to  terminal 


group 

framing  signal  with  balance  bit 
Bl-channel  with  balance  bit 
D-channel  bit  with  balance  bit 
auxiliary  framing  bit  with  balance  bit 
B2-channel  with  balance  bit 
D-channel  bit  with  balance  bit 
D-channel  bit  with  balance  bit 
B2-channel  with  balance  bit 
D-channel  bit  with  balance  bit 


UA 


Frames  transmitted  by  the  network  (NT)  contain  an  echo  channel 
(E-bits)  used  to  re-transmit  the  D-bits  received  from  the  terminals.  The 
D-echo  channel  is  used  for  D-channel  access  control.  The  last  bit  of  the 
frame  (L-bit)  is  used  for  balancing  each  complete  frame. 


The  bits  are  grouped  as  follows  : 


bit  position 


1  and  2 
3  -  10 

11 
12 
13 


group 


framing  signal  with  balance  bit 
Bl-channel 
D-echo  channel  bit 
D-channel  bit 

Reserved  for  future  standardization 
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bit  position 


14 

15 

16  -  23 

24 

25 

26 

27  -  34 

35 

36 

37 

38  -  45 

46 

47 

48 


auxiliary  framing  bit 

N  bit  (Coped  as  defined  in  section  6.3) 

82 -channel 

D-Echo  channel  bit 

D-channel  bit 

Reserved  for  future  standardization 
B  1-channel 
D-Echo  channel  bit 
D-channel  bit 

Reserved  for  future  standardization 

B2-channel  bit 

D-Echo  channel  bit 

D-channel  bit 

frame  balance  bit 


V**,  r.v 
% V* 


microseconds 
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D-channel  access  control 


The  following  procedure  allows  for  a  number  of  terminals  connected  in  ' 
a  multipoint  configuration  to  gain  access  to  the  D-channel  in  an  orderly 
fashion.  The  procedure  ensures  that,  even  in  cases  where  two  or  more  terminals 
attempt  to  access  the  D-channel  simultaneously  one  terminal  will  always  be 
successful  in  completing  transmission  of  its  information. 

6.1.1  Interframe  (layer  2)  time  fill 

Information  on  the  D-channel  is  transmitted  in  layer  2  frames 
delimited  by  flags  consisting  of  the  binary  pattern  01111110.  When  a  TE  or  NT 
has  no  Layer  2  frames  to  transmit,  it  shall  send  binary  "ones"  on  the 
0-channel. 

6.1.2  D-echo  channel 

NT1  or  NT2  on  receipt  of  a  D-channel  bit  from  TE  or  TEs  shall  reflect 
this  condition  in  the  next  available  D-echo  channel  bit  position  towards  the 
terminal! s) . 


6.1.3  D-Channel  Monitorinq 


A  terminal,  while  in  the  active  condition,  shall  monitor  the 
condition  on  the  D-echo-channel  for  the  number  of  consecutive  ONE-bits.  If  a 
ZERO-bit  is  detected  the  terminal  shall  restart  counting  the  number  of 
consecutive  ONE-bits.  The  current  value  of  the  counter  is  called  C. 


(Implementation  dependent) 


6.1.4  Priority  Mechanism 


Layer  2  frames  are  transmitted  in  such  a  way  that  signalling 
information  is  given  priority  (priority  class  1)  over  all  other  types  of 
information  (priority  class  2).  Furthermore  -  to  ensure  that  within  each 
priority  class  all  competing  terminals  are  given  a  fair  access  to  the 
D-channel  -  once  a  terminal  has  successfully  completed  the  transmission  of  a 
frame,  it  is  given  a  lower  level  of  priority  within  that  class.  The  terminal 
is  given  hack  its  normal  level  within  a  priority  class  when  all  terminals  have 
had  an  opportunity  to  transmit  information  at  the  normal  level  within  that 
priority  class. 

The  priority  class  of  a  particular  layer  2  frame  may  be  a 
characteristic  of  the  terminal  which  is  preset  at  manufacture  or  at 
installation  or  it  may  be  passed  down  from  layer  2  as  a  parameter  of  the 
PH-Data  Request  primitive. 


The  priority  mechanism  is  based  on  the  requirement  that  a  terminal 
may  only  start  layer  2  frame  transmission  when  C  (see  section  6.1.3)  is  equal 
to  or  exceeds  the  value  XI  for  priority  class  1  or  is  equal  to  or  exceeds  the 
value  X2  for  priority  class  2.  The  value  of  XI  shall  be  8  for  the  normal 
level  and  9  for  the  lower  level  of  priority.  The  value  of  X2  shall  be  10  for 
the  normal  level  and  11  for  the  lower  level  of  priority. 

In  a  priority  class,  the  value  of  the  normal  level  of  priority  is 
changed  into  the  value  of  the  lower  level  of  priority  when  a  terminal  has 
successfully  transmitted  a  frame  of  that  priority  class.  The  value  of  the 
lower  level  of  priority  is  changed  back  to  the  value  of  the  normal  level  of 
priority  when  the  counter  (see  section  6.1.3)  has  reached  a  value  C  which 
equals  the  value  of  the  lower  level  of  priority. 

6.1.5  Collision  detection 

While  transmitting  information  in  the  D-channel  the  terminal  shall 
monitor  the  received  0-echo  channel  and  compare  the  last  transmitted  bit  with 
the  next  available  D-echo  bit.  If  the  transmitted  bit  is  the  same  as  the 
received  echo,  the  terminal  shall  continue  its  transmission.  If,  however,  the 
received  echo  is  different  to  the  transmitted  bit  the  terminal  shall  cease 
transmission  immediately  and  return  to  the  D-channel  monitoring  state. 

6.1.6  Annex  A  to  this  Recommendation  is  an  example  of  how  the  priority 
system  may  be  illustrated. 
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6.2  ACTIVATION/DEACTIVATION 

6.2.1  Definitions 

6. 2. 1.1  Terminal  Side  equipment  States 

6.2. 1.1.1  STATE  FI:  The  condition  that  the  terminal  is  not 
aware  that  it  is  connected  to  a  physical  interface.  This 
may  be  cuased  by  physically  unplugging  the  terminal  or 
powering  the  terminal  down  so  that  it  is  no  longer 
monitoring  the  interface. 

6.2. 1.1.2  STATE  F2:  After  the  terminal  becomes  aware  that 
it  is  attached  to  an  interface  but  has  not  determined  the 
type  of  signal  that  is  being  transmitted  from  the  network 
side  equipment  (if  any). 

6.2. 1.1.3  STATE  F3:  Deactivated  state  of  the  physical 
protocol.  Neither  network  side  equipment  nor  terminal  side 
equipment  is  transmitting. 

6. 2. 1.1. 4  STATE  F4:  When  the  terminal  side  equipment  is 
requested  to  initiate  activation  it  transmits  a  signal 
(INFO  1)  and  waits  for  a  response  from  the  network  side 
equipment. 

6.2. 1.1.5  STATE  F5:  When  the  terminal  side  equipment 
receives  an  activation  signal  from  the  network  side 
equipment  (INFO  2)  it  responds  with  a  signal  (INFO  5)  and 
waits  for  normal  frames  from  the  network  side  equipment 
(INFO  4). 


6.2. 1.1.6  STATE  F6:  This  is  the  normal  active  state  with 
the  protocol  activated  in  both  directions.  Both  the 
network  side  equipment  and  the  terminal  side  equipment  are 
transmitting  normal  frames. 

6. 2. 1.2  Network  Side  Equipment  States 

6.2. 1.2.1  STATE  Gl:  The  deactive  state;  the  network  side 
equipment  is  not  transmitting. 

6.2. 1.2.2  STATE  G2:  A  partially  active  state  the  network 
site  sends  INFO  2. 

6.2. 1.2.3  STATE  G3:  The  normal  active  state  where  the 
network  side  equipment  to  terminal  side  equipment  direction 
is  active.  The  terminal  side  to  network  side  direction  may 
or  may  not  be  active.  The  network  side  may  deactivate  or 
maintain  the  active  state  when  the  terminal  side  stops 
transmitting.  The  choice  to  eventually  deactivate  is 
completely  up  to  higher  layerprotocols  within  the  network 
side. 
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6. 2. 2. 3  Activate  Primitives 

The  following  primitives  should  be  used  in  the  activate 
procedures.  For  use  in  state  diagrams,  etc.,  abbreviations 
of  the  primitive  names  are  also  given. 

Activate  Request  AR 

Activate  Indicate  AI 

6.2. 2.4  Deactivate  Primitives 

The  following  primitives  should  be  used  in  the  deactivate 
procedures.  For  use  in  state  diagrams,  etc.,  abbreviations 
of  the  primitive  names  are  also  given. 

Deactivate  Request  DR 

Deactivate  Indicate  DI 

NOTE:  Implementation  of  primitives  in  network  and  terminal 
equipment  is  not  for  recommendation. 

6. 2. 2. 5  Time  Outs 


Maximum  times  need  to  be  specified  for  terminal  side 
equipment  response  to  incoming  activation  requests  and  for 
network  side  equipment  response  to  activation  signals. 
These  values  are  subject  to  further  study. 
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6.2.2  SIGNALS 

The  identification  of  specific  signals  across  the  S/T  Reference  Point 
are  given  below.  Also  included  is  the  coding  for  these  signals 


Signals  from  ET  to  TE 

Signals  from  TE  to  ET 

Info  0  no  signal 

Info  0 

no  signal 

Info  1 

A  continious  signal  with 
the  following  pattern: 
positive  zero,  negative  zero 
six  "ones" 

bit  rate  =  192  kbits/sec 

Info  2  Frame  with  all  bits 

of  B,D  and  Echo 
channels  set  to 
zero,  according  to 
the  normal  framing 
rules. 

Info  3 

Not  used  in  the  procedures  at 
this  time.  See  Appendix  10 
of  report  for  definition  and 
discussion  on  use  of  Info  3 

Info  4  Frames  with 

operational  data 
on  B,D  and  Echo 

Channels 

Info  5 

synchronized  frames  with 
operational  data  on  B  and 

D  channels 
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Frame  alignment  procedures 


The  frame  alignment  procedures  make  the  use  of  the  fact  that  the 
framing  signal  is  defined  to  be  a  line  code  violation;  this  allows  a  rapid 
reframing  procedure  to  be  defined. 

According  to  the  coding  rule,  both  the  framing  signal  and  the 
following  binary  zero  data  bit  (in  the  same  frame)  produce  a  code  violation. 

In  the  event,  that  there  are  not  binary  zero  data  bits  in  the  same  frame  then, 
the  auxiliary  framing  (F^)  and  N  bits  (NT  to  TE  direction)  are  coded  as  a 
pair,  such  that  N  is  the  binary  opposite  of  F^.  This  will  ensure  that  there 
is  always  a  code  violation  at  14  bits  or  less  from  the  framing  bit  (F).  In 
the  TE  to  NT  direction  the  F^  and  L  bits  are  coded  according  to  the  normal 
coding  rule. 

6.4.1  Frame  alignment  procedure  in  the  direction  NT  to  TE 

Frame  alignment,  on  initial  activation  of  the  TE  shall  comply 
with  the  procedures  defined  in  section  6.2. 

6.4. 1.1  Loss  of  frame  alignment  may  be  assumed  when  a  time  period 
equivalent  to  two  48  bit  frames  has  elapsed  without  having  detected  valid 
pairs  of  code  violations  obeying  the  ?  14  bit  criterion  as  described  above. 
The  TE  shall  cease  transmission  immediately. 

6.4. 1.2  Frame  realignment  may  be  assumed  to  occur  when  3  consecutive 

pairs  of  line  code  violations  1)  obeying  to  ?  14  bit  criterion  have  been 

detected. 


If  it  is  not  possible  to  achieve  frame  realignment  within  a  time 
period  equivalent  to  9  X  3  frames,  the  TE  shall  continue  to  transmit  INFO  Q 
(see  note  2) 

Notes  :  1  -  The  reframing  procedure  does  not  depend  on  the  polarity  of  the 

code  violations,  i.e.  it  is  not  sensitive  to  wiring  polarity 

2  -  Other  actions,  e.g.  informing  the  management  entity  requires 

further  study 

3  -  The  value  of  ?  is  dependent  on  performance  and  requires 

further  study. 

6.4.2  Frame  alignment  in  the  direction  TE  to  NT 

In  the  direction  TE  to  NT  the  F/\  and  L  bits  are  always  coded 
according  to  the  coding  rule  such  that  binary  F^  and  L  are  equal.  The 
criterion  of  a  code  violation  at  13  bits  or  less  from  the  framing  bit  (F) 
shall  apply.  The  NT  shall  assume  loss  of  frame  alignment  if  a  time  period 
equivalent  to  two  48  bit  frames  has  elapsed  since  detecting  cr  <-<  utive 
violations  according  to  the  12  bit  criterion.  On  detection  of  loss  of  frame 
the  NT  shall  continue  transmitting  towards  the  TE.  The  NT  shall  assume  that 
frame  alignment  has  been  regained  when  those  consecutive  pairs  of  code 
violations  obeying  the  12  bit  criterion  have  been  detected. 


If  after  Q*  attempt  to  realign  the  NT  is  still  unable  to  regain 
frame  alignment  the  NT  shall  send  Info  0  towards  the  TE  and  inform  layer  2  by 
means  of  the  PH  deactivate  Indication  (Note:  the  implementation  of  this 
primitive  depends  on  the  NT-ET  transmission  system  which  is  not  subject  to 
CCITT  Recommendations). 

6.4.3  Multiframing 

The  use  of  multiframing  and  the  definition  of  multframe 
structures  requires  further  study.  ** 

Note  that  the  coding  of  and  N  bits  as  defined  in  section 
6.4  may  be  used  to  provide  a  multiframe  capability  and/or  other  functions  yet 
to  be  defined. 

**  Pending  such  study,  the  F/\  hit  will  be  set  to  binary  on  both  directions 
of  transmission. 


*)  Note:  the  value  of  Q  is  network  dependent  and  will  not  be  specified.  -  \ 
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6.4  Frame  alignment  procedures  S' 

/  / 

The  frame  alignment  procedures  make  use  of  the  fact  that  they'framing  signal 
is  defined  to  he  a  line  code  violal^on,  this  allows  a  rapid  reframing  procedure  to 
be  defined.  /  / 


According  to  the  coding  rule,  both  the  framing  signal 
binary  zero  data  bit  (in  the  /Same  multiframe)  produce  a  code  violation. 


nd  the  following 
In  the 

event  that  there  are  no  binary  zero  data  bits  in  the  same  mul^Ciframe  then  the 
auxiliary  framing  bit  Fa, /Which  occurs  13  bit  positions  aft^r  the  frame  alignment 
signal,  and  is  coded  as  jL  binary  zero,  will  produce  a  cod^violation. 


6.4.1 


Frame  a 


lignui' 


ent  procedure  in  the  direction  NT/to  TE 


A  terminal  shall  search  for  line  code  vi options.  Having  detected  a 
violation,  a  count  of  the  number  of  bits  until  the  iiext  violation  shall  be  initiated. 
If  the  count  is  23  or  less  (the  distance  between  the  framing  and  auxiliary  framing 
bits)  then  the  >first  violation  shall  be  taken  toAndicate  the  true  framing  positio/f. 
For  any  other Aalue  of  the  counter  it  shall  be  /ssumed  that  true  framing  has  noty6een 
achieved  andAhe  search  shall  continue. 


.V 


Rote  that  this  reframing  procedural  does  not  depend  on  the  polar ityy6f 
the  code  violations,  i.e.the  system  is  notAensitive  to  wiring  polarity. 

/  In  the  instance  of  loss  of  fra^le  alignment  an  ERROR  primitive  jliall  be 
passed/from  layer  1  to  layer  2. 


6.4./ 


Frame  alignment  procedure  l/  the  direction  TE  to  NT 


/a 


J  The  same  alignment  procedure  shall  be  used  as  in  the  NT  Vo  TE  direction. 

IV  should  be  noted  however  that  fdr  some  applications,  e.g.  on  a  /hort  passive 
Ijfiis  where  the  round  trip  delay  iy  less  than  one  bit,  it  is  possible  to  use  a  receiver 
In  the  NT  with  fixed  timing.  / 

6.4.3  Multiframing  /  / 

Multiframing  i3  fnr  further  study.  (Note  that  it  is  intended  that,  in 
the  direction  TE  to  NT,  th^  Fa  bit  may  only  be  required  in  one  out  of  four  frames. 

The  bits  in  the  14th  bit  position  of  the  other  frames  may  be  used  for  other 
purposes,  yet  to  be  defined.  Such  use  would  require  a  multiframe  capability.) 
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8. 

Electrical  characteristics 

8.1 

Bit  rate 

8.1.1 

Nominal  rate  . 

.  192  kbit/s 

8.1.2 

Tolerance  (free  running  mode)  +  100  ppm 

8.2 

Jitter  and  bitphase  relationship  between  TE 

input  and  output 

8.2.1 

Test  configuration 

The  jitter  and  phase  deviation  measurements 

are  carried  out  with  four 

different  waveforms  at  the  terminal  input  in  accordance  with  following 
configurations: 


i)  point-to-point  configuration  with  6  dB  cable  attenuation 
measured  between  two  terminating  resistors,  as  measured  at  %  kHz 

ii)  short  passive  bus  with  8  clustered  terminals  at  the  end  (high 
capacitance  cable) 

iii)  short  passive  bus  with  1  terminal  near  to  NT  and  7  clustered 
terminals  at  the  end  (low  capacitance  cable) 

IV)  back  to  back  condition  with  1  terminal  (without  cable) 

Examples  for  waveforms  i,  ii,  iii  and  a  test  configuration  which 
can  generate  these  signals  are  given  in  Annex  2. 

Other  possible  test  conditions  and  the  parameters  of  the 
artificial  line  have  to  be  identified  and  are  for  further  study. 

8.2.2  Timing  extraction  jutter  due  to  TE  +  7  %  of  a  bit  period, 
measured  with  high  pass  filter  with  a  cut  off  frequency  of  30  Hz  under  test 
conditions  described  in  8.2.1  with  all  possible  test  patterns. 

Worst  case  test  pattern  is  for  further  study. 

8.2.3  Phase  deviation  between  TE  input  and  output  -7  ...  +15%  of  a  bit 
period  using  as  reference  crossings  of  zero  volt  between  framing  pulses  and 
associated  balance  pulses.  The  phase  deviation  has  to  be  measured  under  test 
conditions  described  in  8.2.1  with  all  possible  test  patterns.  Additionally, 
the  test  signal  at  the  output  of  the  pattern  generator  has  to  be  modulated 
with  sinusoidal  jitter  as  given  below. 
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8.3.1  Maximum  output  jitter  (p-p)  5*  of  a  bit  period  measured  with  high  pass 
filter  with  a  cut  off  frequency  of  fg  Hz. 

8.4  Termination  of  the  line 

Terminating  resistor  100«A-+5!t 

(see  figure  1/1.431}^”  / 

8.5  Transmitter  output  characteristics 

8.5.1  Transmitter  output  impedance 

8. 5.1.1  NT  transmitter  output  impedance 


In  all  states  including  the  inactive  state  To  exceed  template 

at  interface  point  I  (see  figure  1/1.431)  (Figure  8. 5. 1.1) 

n 

Note  :  In  some  applications  the  terminating  resistor  can  be  combined  with  the  NT 
(see  fig.  1/1.431,  point  b),  the  resulting  impedance  is  the  combination  of 
impedance  needed  to  exceed  the  template  and  of  the  termination. 

8. 5. 1.2  TE  transmitter  output  imperial.. 

l.i  all  states  including  the  inactive  state  To  exceed  template 

at  interface  point  I  (see  figure  1/1.431)  (Figure  8. 5. 1.2) 
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8. 5. 3. 2 
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Test  load  impedance .  50  ohms 

(unless  otherwise  indicated) 

Pulse  shape  and  amplitude  (logical  "0") 

Pulse  shape . within  mask  Figure  8.3.1 

Nominal  pulse  amplitude  (zero  to  peak)  750  mV 
A  positive  +  at  the  output  parts  of  the  NT  and  TE  is  defined  as  a 
positive  polarity  from  3-4  and  5-6  of  the  interface  respectively. 

The  pulse  unbalance,  the  difference  in j'  Uft)dt  for  positive 
pulses  andju(t)dt  for  negative  pulses  ^  5% 

Voltage  on  other  test  loads  (other  than  50-^  ) 


8.5.5. 1  Overvoltage  with  400  -A.  load 


within  mask  Figure  8.5.5 


8. 5. 5.2  Voltage  with  5,  6w/lload 


within  mask  Figure  8.5.5 


8.5.6  Unbalance  about  earth 

(measured  by  considering  the  power  feeding  and  two 
100-ohm-terminations  at  each  port) 
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8.5.6. 1  Longitudinal  conversion  loss  (LCL) 

in  accordance  with  G.117,  item  4.2.3, 

(see  figure  8.5.6. 1) 

a)  10kHz  S  f  <  300  kHz  £  60  dB 

b)  above  30  kHz  up  to  1  MHz  decreasing  with  20  dB/decade 

8. 5. 6. 2  Output  signal  balance 

in  accordance  with  G.117,  item  4.3.1 
(see  figure  8. 5. 6. 2) 

100  kHz  60  dB 

decreasing  with  20  dB/decade  up  to  1  MHz 


K' 


& 

& 


$ 

w 

A  j 

m 


§ 

& 


A.V  -v 


\  s  %  ^  v. 

■  -\-V.VA.V 


•  w  m  > 


.S’  -i 
1 

V.-i 


V*-  - 

•v*  »*\j 

aV* 

h  -  »  I 


jzo 


TE  (NT  ) 


I  1 


*s 


LONGITUDINAL  CONVERSION  LOSS  (LCL)  =  20  ( log  10  j-^y- 1 )  d B 

THE  VOLTAGES  VT  ANO  E L  SHOULD  BE  MEASURED  WITHIN  THE  FREQUENCY  RANGE 
FR0M10KHZ  UP  TO  1MHZ  BY  APPLYING  A  SELECTIVE  TEST  EQUIPMENT. 

THE  MEASURING  IS  TO  CARRY  OUT  IN  THE  STATE 
-DEACTIVATED  I  REC.  .  SEND  1 

-PARTIALLY  ACTIVATED  {  REC.  ,  SEND.  J 

-ACTIVATED  I  REC.) 

NOTE  II 

THE  SHOWN  RESISTOR  MUST  BE  OMITTED  IF  THE  TERMINATION 
IS  ALREADY  BUILT-IN  THE  TEINTI  . 

NOTE  2)  . 

HANDIMITATION  -  C,  7  Tr> 


RECEIVER  INPUT  OR  TRANSMITTER  OUTPUT 
UNBALANCE  ABOUT  EARTH 


FIGURE  8  C£l 


TE  (NT 


(SOURCED 


z  h 2 

lOOnU  100  n 


GROUND  Mm  «  1m  HETAL  PLATE  ) 


OUTPUT  SIGNAL  BALANCE  =  20  ( log  1Q  |yp| )  dB 

THE  VOLTAGES  VT  AND  VL  SHOULD  BE  MEASURED  WITHIN  THE  FREQUENCY  RANGE 
FROM  10KHZ  UP  TO  1MHZ  BY  APPLYING  A  SELECTIVE  TEST  EQUIPMENT. 

THE  MEASURING  IS  TO  CARRY  OUT  IN  THE  ACTIVE  STATE 
BY  MEANS  OF  A  SUITABLE  SIGNAL  PATTERN 


NOTE  II 

THE  SHOWN  RESISTOR  MUST  BE  OMITTEO  IF  THE  TERMINATION 
IS  ALREAOY  BUILT-IN  THE  TEINTI 
NOTE  2) 

HANDIMITATION 


TRANSMITTER  OUTPUT 
UNBALANCE  ABOUT  EARTH 


FIGURE  « Sto 
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8.6  Receiver  input  characteristics 

8.6.1  Receiver  input  impedance 

8. 6. 1.1  TE  receiver  input  impedance 


To  exceed  template 
(Fig.  8, 5. 1.2.) 


In  all  states  including  the  inactiye  state 
at  interface  point  1^  (see  fig.  i/I, 1*31) 

8. 6. 1.2  NT  receiver  input  impedance 

In  all  states  including  the  inactiye  state  To  exceed  template 
at  interface  point  IB  (see  fig,  1/1.1*31)  (fig,  8,5, 1.1) 

Note  :  In  some  applications  the  terminating  resistor  can  he  combined 
with  the  NT  (see  fig.  1/1,1*31  point  B)  the  resulting  impedance 
is  the  combination  of  impedance  needed  to  exceed  the  template  and  of  the 
termination. 

8.6.2  Receiver  sensitivity  and  noise  immunity 

The  measurement  method  requires  further  study. 

8.tf.3  NT  receiver  input  delay  characteristics 


8.£.3. 1  Point-to-point  requirements  . .  up  to  6  bits 

(Round  trip  delay) 

8. £.3. 2  Simple  (short)  passive  bus  requirements  . 0  -  2.5  PS 

(Round  trip  and  differential  round  trip  delay) 

8.£-3-3  Branched  star  (or  extended  bus)  . '. . 

Round  trip  delay . up  to  6  bits 

Differential  round  trip  delay  . . . .  .  0  -  0.5  pS 


8.&*  Unbalance  about  earth 

Longitudinal  conversion  loss  measured  In  accordance 
with  G.117,  item  *.1.3*  by  considering  the  power  feeding 
and  two  100-ohm- terminations  at  each  port. 

(See  figure  8.£&1) 

a)  10  kHz  i  f  <  300  kHz  *60  dB 

b)  above  300  kHz  up  to  1  MHz  decreasing  with  20  dB/decade 


8.7  Isolation  from  external  voltages  Further  study 

8.8  E.M.I.  Generation  Further  study 


10.  Mechanical  characteristics 
For  further  study. 
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Power  feeding 
9. 1  Reference  configuration 

The  reference  configuration  for  power  feeding,  based  on  an  eight  pins 
interface  connector  is  described  in  Figure  4/1.431.  The  use  of  four  access 
leads  (3,  4,  5,  6)  is  mandatory,  the  use  of  the  remaining  four  (1,  2,  7,  8)  is 
optional . 


This  reference  configuration  allows  unique  physical  and  electrical 
characteristics,  for  the  interface  at  reference  points  S  and  T,  which  are 
independent  of  the  choice  of  internal  or  external  power  sources  arrrangements. 

Power  source  1  may  drive  its  power  from  the  network  and/or  locally 
(including  batteries).  Power  source  2  derives  its  power  locally  (including 
batteries) . 

9.1.1  Functions  specified  at  the  eight  access  leads 

The  eight  access  leads,  for  TE  and  NT  should  he  applied  as  follows: 

a)  access  leads  3-4  and  5-6  whose  provision  is  mandatory,  are 
strictly  reserved  for  the  bi-directional  transmission  of  the  digital  signal 
and  may  provide  a  phantom  circuit  for  power  transfer; 

b)  access  leads  1-2  and  7-8,  whose  provision  for  power  feeding  is 
optional  may  be  used  for  additional  power  transfer  from  NT  to  TE; 

c)  access  leads  1-2  and  7-8,  whose  provision  is  optional,  may  be  used 
for  power  transfer  in  TE-TE  interconnection.  This  characteristic  of  the  power 
on  these  leads  are  not  the  subject  of  a  CCITT  Recommendation. 

Note  1  :  Power  source  2  -  Provision  of  this  source  is  subject  to  the 
decision  of  individual  administrations. 

Note  2  :  Where  the  power  source  1  is  provided,  the  minimum  powers 
available  from  this  source  on  the  phantom  are  to  be  specified  during  the 
normal  condition.  The  provision  of  power  greater  than  the  minimum  is  the 
responsibility  of  the  individual  Administrations. 

Note  3  :  Power  sink  2  is  optional. 

Note  4  :  Power  source  3  is  not  subject  to  CCITT  Recommendations. 

Note  5  :  Power  sink  1  is  optional.  Administrations  may  limit  the  use 
of  the  power  from  the  phantom  to  those  terminals  capable  of  providing  a 
minimum  service. 

Note  6  :  The  numbering  of  leads  in  Figure  4/1.431  does  not  imply  any 
assumption  on  pin  allocation  or  physical  connectors. 

Note  7  :  Maintenance  of  polarity,  on  a  wired  pair  cannot  be 
guaranteed  in  all  cases.  This  must  be  taken  into  consideration  for  terminals 
drawing  power  from  7-8  access  leads. 

Note  8  :  Power  source  1  may  not  always  be  provided. 

Note  9  :  It  should  be  noted  that  a  terminal  that  is  to  be  portable 
(e.g.  from  network-to-network,  country-to-country)  can  not  rely  exclusively  on 
phantom  power  for  its  operation. 
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Power  available  from  NT 


A.  1  26 


Two  different  situtations  are  identified  relative  to  power  feeding: 

9.2.1  Minimum  power,  Py' ,  available  from  source  1  on  the  phantom  using  local 
mains  power  or  an  equivalent  level  of  power  from  the  network  (or  a  combination  of 
local  and  network  power).  The  provision  of  power  P^will  be  the  responsibility  of 
individual  administrations. 

9.2.2  a)  minimum  power,  P< *  ,  available  from  source  1  on  the  phantom  (eg  when 
mains  powering  is  unavailable  or  not  provided  at  the  NT).  The  value  ,  should  be 
400  mW  (1).  This  may  be  the  only  available  power  in  case  of  emergency. 

b)  emergency  condition.  The  emergency  condition  exists  when  the  NT  looses 
power  from  the  mains.  When  the  NT  is  only  able  to  deliver  Pd  ,  this  condition  is 
indicated  by  the  NT  in  changing  the  polarity  of  the  voltage  over  the  phantom 
circuit.  In  this  condition  only  emergency  functions  of  terminals  are  allowed  to 
draw  power  from  the  phantom  circuit. 

Note  (1)  :  This  value  of  P^  is  provisional  and  a  lower  value  (eg  :  250  mW)  is 
subject  to  further  study  over  the  next  study  period. 

9.3  Power  available  at  TE  -  Phantom  mode  (access  lead  3.4  and  5.6) 

9.3.1  Voltage 

The  voltage  at  the  input  to  the  TE  will  be  : 

a)  normal  conditions,  X  volts  +5  X 

-y 

b)  emergency  conditions,  -  (X  volts  +5  X  ) 

-Z 

(For  X,  a  choice  should  be  made  between  24v  or  40v. ) 

(The  tolerances,  y  and  z  are  for  further  study) 

(The  value  of  5%  is  based  on  40v  for  X,  and  might  be  higher  for  24v  [Max 
safe  voltage  is  42. 5v.]) 

9.3.2  Current 


The  maximum  current  available  at  the  input  to  a  TE  in  order  to  remain 
above  the  minimum  voltage  (X  volts-zX)  under  emergency  conditions  is  I  ma. 

(The  value  of  current  I  is  for  further  study) 

9.4  Current  transient 

The  rate  at  change  of  current  drawn  by  a  TE  (when  connected  or  as  a  result 
of  a  polarity  change  for  emergency  conditions)  shall  not  exceed  R  ma//us. 

(The  value  R  is  for  further  study) 

9.5  Power  down  mode  consumption 

The  power  down  mode  consumption  of  a  TE  must  be  less  than  W  watts  (W 
should  be  choosen  in  the  range  of  0  to  50  mW). 

Title  of  4/1.431  is  "Reference  configuration  for  power  feeding  under  normal 
operating  mode. 

Add  "RECEIVE"  at  NT  terminals  5-6  and  "TRANSMIT"  at  NT  terminals  4-3. 
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aendix  1 


Elements  for  layer  to  layer  ccnmuni cations 


General 


Overview  definition  of  primitives 


All  communications  between  layers  are  accomplished  by  primitives. 
Primitives  consist  of  command  and  their  respective  responses  associated  with  the 
services  requested  of  a  lower  layer.  The  general  syntax  of  a  primitive  is  : 


XX  —  Generic  Name  —  Specific  Name  :  PARAMETERS 


The  XX  designates  the  layer  providing  the  service.  For  this 
Recommendation  XX  has  the  values  DL  for  Data  Link  layer  and  PH  for  Physical  Layer. 
The  generic  name  specifies  the  action  that  the  addressed  layer  should  perform.  The 
primitive  generic  names  that  are  used  in  this  Recommendation  are  shown  in  the  first 
column  of  Table  1/1.430  (431).  The  specific  name  indicates  the  direction  of  the 
primitive  flow.  In  Table  1  the  specific  primitive  names  that  are  used  in  this 
Recommendation  label  the  next  four  columns.  The  specific  name  REQUEST  is  used  when 
a  higher  layer  is  requesting  a  service  from  its  next  lower  layer.  The  specific  name 
INDICATION  is  used  when  the  layer  providing  the  service  wants  to  notify  the  next 
higher  layer  of  activity  associated  with  the  generic  name.  The  specific  name 
RESPONSE  is  used  by  a  higher  layer  to  acknowledge  a  receipt  of  an  INDICATION 
primitive.  The  specific  name  CONFIRM  is  used  by  the  layer  providing  the  requested 
service  to  confirm  that  the  action  has  been  completed.  The  sequence  of  events  is 
shown  in  Figure  1. 


Note  that  not  all  generic  names  contain  all  four  specific  names.  The 
parameters  associated  with  each  primitive  generic  name  are  shown  in  Table  2/1.431. 
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ANNEX  1 


(to  Recommendation  1.431) 


W  i  r  i ng  configurations  and  interconnecting  media  characteristics 
used  as  a  basis  for  electrical  characteristics 


1 .  Introduction 

1.1  In  section  4  of  Rec  1.431  two  major  wiring  arrangements  are 
identified.  These  are  a  point-to-point  configuration  and  a 
point-to-multipoint  configuration  using  a  passive  bus. 

While  these  configurations  may  be  considered  to  be  the  limiting  cases 
for  the  definition  of  the  interfaces  and  the  design  of  the  associated  TE  and 
NT  equipments,  other  significant  arrangements  should  be  considered. 

1.2  The  values  of  overall  length  and  delay  assumed  for  each  of  the 
possible  arrangements  are  indicated  below 

1.3  Figure  1/1.431  of  the  Recommendations  is  a  composite  of  the 
individual  configurations.  These  individual  configurations  are  shown  in  this 
Annex. 


2.  Wiring  configurations 


2.1  Point-to-point 


This  configuration  provides  for  one  transmitter/receiver  only  at  each 
end  of  the  cable  (see  Fig.  A. 2.1.  It  is  therefore  necessary  to  determine  the 
maximum  permissible  attenuation  between  the  ends  of  the  cable,  to  establish 
the  transmitter  output  level  and  the  range  of  receiver  input  levels.  In 
addition,  it  is  necessary  to  establish  the  maximum  round  trip  delay  for  any 
signals  which  must  be  returned  from  one  end  to  the  other  within  a  specified 
time  period  (limited  by  echo  0  bits) 


A  general  objective  for  the  operational  distance  (measured  at  96  kHz) 
between  TE  and  NT  or  NT!  and  NT2  is  1.0  km.  It  is  agreed  to  satisfy  this 
general  objective,  that  a  maximum  cable  attenuation  of  6  dB  and  a  round  trip 
delay  of  6  bit  periods  (at  192  kbit/s)  are  the  objectives  for  the  definition 
of  the  electrical  characteristics.  It  should  be  noted  that  an  adaptive  timing 
device  at  the  receiver  is  required  at  the  NT  to  meet  these  limits. 


Ry  this  type  of  wiring  configuration  it  is  also  possible  to  provide 
point-to-multipoint  mode  of  operation  at  Layer  1.  One  example  (active  bus)  is 
shown  in  Figure  A. 2. 2. 


2.2  Point-to-multipoint 


2.2.1  In  addition  to  the  "short  passive  bus"  identified  in  section  2  of  the 
Recommendation,  other  configurations,  such  as  an  "extended  passive  bus"  may  be 
used  to  provide  for  point-to-multipoint  type  of  configuration. 


An  essential  configuration  to  he  considered  is  a  passive  bus  in  which 
the  TE  devices  may  he  connected  at  random  points  along  the  full  length  of  the 
cable.  Because  this  means  that  the  NT  receiver  must  cater  for  pulses  arriving 
with  different  delays  from  various  terminals,  a  length  limit  for  this 
configuration  is  a  function  of  the  maximum  round  trip  delay  and  not  the 
attenuation.  An  NT  receiver  with  fixed  timing  can  be  used  if  the  round  trip 
delay  is  restricted  to  2.5  uses.  This  relates  to  a  maximum  operational 
distance  from  the  NT  in  the  order  of  100  -  150  metres.  It  should  be  noted 
that  the  TE  connections  act  as  stubs  on  the  cable  thus  reducing  the  NT 
receiver  margin  over  that  of  an  equipment  point-to-point  configuration.  A 
maximum  of  8  stubs  of  10  metres  in  length  are  to  be  accommodated. 

2.2.3  Extended  passive  bus  (or  branched  star)  (Fig.  A. 2. 4) 

A  configuration  which  may  be  used  at  an  intermediate  distance  between 
100  metres  and  1.0  km  is  known  as  the  extended  bus.  It  takes  advantage  of  the 
fact  that  terminal  connection  points  are  restricted  to  a  signal  grouping  at 
the  far  end  of  the  cable  from  the  NT.  This  places  a  restriction  on  the 
differential  distance  between  TE's.  The  objectives  for  this  configuration  are 
a  total  length  of  500  m  and  a  differential  distance  between  terminal 
connection  points  of  35  metres. 

The  achievable  limits  for  this  configuration  would  be  a  compromise 
based  on  the  limiting  receiver  characteristics  proposed  for  the  other  two 
configurations  2.2.1  and  2.2.2. 

3.  Interconnecting  media  characteristics 

These  characteristics  have  been  used  for  the  derivation  of  the 
distances  indicated  in  the  wiring  configurations.  They  are  also  necessary  for 
the  determination  of  the  sitnal  characteristics  at  the  receiver  input  in  the 
different  configurations. 

The  most  important  parameters  directly  related  with  the 
characteristics  of  the  interface  are  indicated  below: 


Effective  capahity 
(as  defined  in  G. <51 1 ) 

c  t 

120  nF/km 

at 

1  kHz 

Magnitude  of  the  Impedance 

700  t 

1Z1  150 

at 

100  kHz 

Group  delay 

i*  : 

9us/km 

at 

100kHz 

Longitudinal  conversion  loss 


LCL  s  43  dB  at  100  kHz 

(values  are  provisional) 
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ANNEX  2  to  draft  Recommendation  1.431 


Jitter  and  bit  phase  relationship  between  TE  input  and  output  at  So  interface 

The  fixed  delay  and  jitter  (p-p )  due  to  TE  represent  one  of  the 
limiting  factors  of  the  length  of  the  passive  bus  while  the  jitter  is  the  most 
important  parameter  in  point  to  point  configuration. 

In  addition  to  the  ideal  waveform  (see  figure  8.5.3. 1,  p.7)  the 
following  three  waveforms  are  used  for  the  measurement  : 


A  possible  way  to  generate  these  waveforms  is  illustrated  in  figure 
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State  Name 

DEACT 

PEND 

INFO  SENT 

0 

2 

INFO  RECEIVED 

0.5 

0.1 

State  Number 

GI 

G2 

\ctivate  Request 

G2,I2 

Jeactivate  Request 

GI  :I0 

[NFO  0  (Note  I) 

:nfo  1 

G2.I2 

NFO  5 

G3;I4 

;AI 

Time  Out  (Note  3) 

GI  ;0I 

;io 

.ost  Framing  (Notejl) 

| 

ACT 


4 

0.5 


63 


G1 : 10 


61:10 


G1;I0 

;DI 


Note  1  :  The  time  needed 
to  react  to  lost  framing 
or  10  is  network  dependent 
and  may  be  of  long  duration 


Note  3:  Value  for  Time 
is  a  subject  for  further 
study. 


States 

GI 

DEACT 

Physical  Connection  Inactive 

G2 

PEND  ACT 

Activation  Initiated 

G3 

ACT 

Physical  Connection  Active 

Notation  Conventions 


Remain  in  current  state 
/:  Cannot  occur  or  discard 
Gi:  Go  to  state  Gi 
Ii:  Send  info  i 
AI:  Generate  PH  AI  Primitive 
DI:  Generate  PH.DI  Primitive 
State  Timer 
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1.  General 

An  ad  hoc  Group  under  the  chairmanship  of  Mr.  F.  E.  Weber  (United 
States,  ATT)  met  to  consider  proposed  changes  to  the  draft  Recommendation 
1.432  which  specifies  layer  1  of  the  primary  rate  user/network  interface. 

The  terms  of  reference  set  out  by  the  Chairman  of  Working  Team  2  were: 

-  to  review  proposed  modifications  to  Recommendation  1.432; 

-  to  produce  a  revised  draft  text. 

2.  Documents 

The  following  documents  in  addition  to  COM  XVI I I-R18  were  considered: 
SS  (Federal  Republic  of  Germany),  TM  (NTT)  and  TW  (ATT). 

3.  Discussion  of  draft  Recommendation  1.432 


As  suggested  in  Contributions  SS  (Federal  Republic  of  Germany)  and  TW 
(ATT),  it  was  agreed  to  replace  the  sections  of  Recommendation  I. 432 
specifying  electrical  characteristics  by  references  to  the  relevant  sections 
of  Recommendation  G.703.  This  will  minimize  the  possibility  that 
unintentional  differences  are  introduced  into  Recommendation  1.432. 

References  to  other  Recommendations  (e.g.  G.733)  have  been  made  as  appropriate. 

The  revised  draft  text  includes  proposed  time  slot  assignments  for 
H0-channels.  These  assignments  are  as  proposed  in  Contributions  SS  (Federal 
Republic  of  Germany)  for  2048  kbit/s  and  TM  (NTT)  for  1544  kbps.  The  time 
slot  assignments  cover  the  cases  where  either  B-  or  H0-channels  (but  not 
both)  are  present  simultaneously  on  the  interface. 


For  the  case  where  B  and  Hq  are  mixed,  two  possible  arrangements 
have  been  identified.  The  first  utilizes  a  fixed  allocation  for  H0-channels 
using  consecutive  time  slots  and  permits  unused  time  slots  to  be  used  for 
B-channels.  The  second  permits  a  completely  flexible  assignment  of  time  slots 
to  form  B-  and  H0-channels.  Both  of  these  approaches  are  for  further  study. 
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During  the  discussion  on  functional  requirements  it  was  pointed  out  that 
the  definition  of  some  terms  (e.g.  B-channel,  octet  timing)  are  in  some  cases 
unclear.  Since  these  definitions  are  common  to  several  texts  (e.g.  1.431,  1.432), 
it  is  suggested  that  they  be  reviewed  by  the  Vocabulary  Group  to  be  made  more  precise. 


Draft  Recommendation  1.432 


PRIMARY  RATE  USER/NETWORK  INTERFACE  -  LAYER  1  SPECIFICATION 


1.  Introduction 

This  Recommendation  is  concerned  with  the  layer  1  electrical,  format  and 
channel  usage  .characteristics  of  the  primary  rate  user/network  interface  at  the 
S  and  T  reference  points.  Interfaces  for  the  1544  kbps  primary  rate  and  for  the 
2048  kbps  primary  rate  are  described.  As  an  ultimate  objective,  the  same  primary 
rate  user/network  interface  should  be  operable  at  1544  kbps  and  2048  kbps  with  the 
same  TE/NT2  equipment.  Any  differences  between  the  interface  specifications  for 
the  two  rates  should  be  kept  to  a  minimum. 

This  Recommendation  is  based  on  CCITT  Recommendations  G.703,  G.732,  G.733 

and  G.734. 

In  the  future,  alternate  interface  arrangements  suitable  for  new 
technologies  (e.g.  fibre  optics),  different  applications  (e.g.  longer  transmitter- 
receiver  distance),  etc.,  may  be  specified. 


1.1  Scope  and  field  of  application 


This  specification  is  applicable  to  user/network  interfaces  at  1544  kbit/s 
and  2048  kbit/s  primary  rates  for  ISDN  channel  arrangements  as  defined  in  draft 
Recommendation  1.412. 

2.  Type  of  configuration 

The  type  of  configuration  applies  only  to  the  layer  1  characteristics  of 
the  interface  and  does  not  imply  any  constraints  on  modes  of  operation  at  higher 
layers . 

2.1  Point-to-point 

The  primary  rate  access  will  support  only  the  point-to-point  configuration 

Point-to-point  configuration  at  layer  1  implies  that  only  one  source 
(transmitter)  and  one  sink  (receiver)  are  connected  to  the  interface.  The  maximum 
reach  of  the  interface  in  the  point-to-point  configuration  is  limited  by  the 
specification  for  the  electrical  characteristics  of  transmitted  and  received  pulses 
and  the  type  of  interconnecting  cable.  These  characteristics  are  as  defined  in 
Recommendation  G.703. 
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Functional  characteristics 


Summary  of  functions 


B- channel 

This  function  provides  for  the  bi-directional  transmission  of  independent 
B-channel  signals  each  having  a  bit  rate  of  64  kbit/s  as  defined  in  Recommend¬ 
ation  1.412. 

Hp-channels 

This  function  provides  for  the  bi-directional  transmission  of  independent 
Ho-channel  signals  each  having  a  bit  rate  of  384  kbit/s  as  defined  in 
Recommendation  1.412. 

Hi -channel 

This  function  provides  for  the  bi-directional  transmission  of  an  H^-channel 
signal  having  a  bit  rate  of  1536  or  1920  kbit/s  as  defined  in  Recommendation  1.412.  . 

( tJa-r-  ye  t  //■/  J  .h'S-  —  5,  j 

D-channel  or  E-channel 

This  function  provides  for  the  bi-directional  transmission  of  one  D-channel 
signal  or  one  E-channel  signal  at  a  bit  rate  of  64  kbit/s  as  defined  in 
Recommendation  1.412. 


This  function  provides  bit  (signal  element)  timing  to  enable  the  terminal 
or  NT  to  recover  information  from  the  aggregate  bit  stream. 

Octet  timing 

This  function  provides  8  kHz  timing  towards  the  terminal  or  NT  for  the 
purpose  of  enabling  an  octet  structure  for  PCM  voice  coders  and  for  other  timing 
purposes  as  required. 

Frame  alignment 

This  function  provides  information  to  enable  the  terminal  or  NT  to  recover 
the  time-division  multiplexed  channels. 

Maintenance 

The  definition  and  use  of  these  functions  are  for  further  study. 

3.2  Interchange  circuits 

Two  interchange  circuits,  one  for  each  direction,  are  used  for  the 
transmission  of  digital  signals.  All  the  functions  above-listed,  with  the  possible 
exception  of  maintenance,  are  combined  into  two  composite  digital  signals,  one  for 

each  direction  of  transmission. 
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4.  Interface  at  1544  kbit/s 

4.1  Electrical  characteristics 

This  interface  should  conform  to  Recommendation  B.703,  section  2, 
which  recommends  the  basic  electrical  characteristics  of  this  interface,  such 
as  bit  rate,  pulse  shape,  impedance,  and  code.  The  B8ZS  format  is  recommended 
for  ISDN  use. 

Note  -  It  is  recognized  that  revisions  to  Recommendation  G.703  are  expected  as 
a  result  of  studies  under  Q. T5/XVI 1 1  (see  COM  XVIII-R  13,  section  II. 4. 1, 
which  describes  B8ZS)  and  it  is  intended  that  the  reference  given  here  will  be 
to  the  revised  version  as  finally  adopted.  (This  Not  is  to  be  removed  in 
final  drafting.) 

Note  -  A  CM I  (Coded  Mark  Inversion)  code  was  proposed  as  an  alternative  to  the 
B8ZS  code  for  the  ISDN  1544  kbit/s  user/network  interface.  Selection  of  a 
line  code  for  future  application  should  be  made  after  extensive  studies  and 
comparison  between  these  two  codes  have  been  carried  out  taking  into  account 
future  possible  media  such  as  optical  fibre  and  radio. 

4.2  Frame  structure 

4.2.1  24-frame  multiframe 

4.2. 1.1  The  frame  structure  is  based  on  Recommendation  G.733  and  is  shown  in 
Figure  1/1.432. 

4.2. 1.2  Each  frame  is  193  bits  long  and  consists  of  an  F-bit  followed  by  24 
consecutive  time  slots,  numbered  1  to  24. 

4.2. 1.3  Each  time  slot  consists  of  8  consecutive  bits,  numbered  1  to  8. 

4.2. 1.4  The  frame  repetition  rate  is  8,000  frames/sec. 

4.2. 1.5  The  multiframe  structure  is  shown  in  Table  1/1.432.  Each  multiframe 
is  24  frames  long  and  is  defined  by  the  multiframe  alognment  signal  (FAS) 
formed  by  every  fourth  F-bit. 

4.2. 1.6  The  bits  ej  to  e6  in  Table  1/1.432  are  used  for  error  checking  in 
G.733,  section  2.1.5.  Their  use  in  this  recommendation  is  for  further  study. 
The  use  of  the  M  bits  is  for  further  study. 

4.3  Time  slot  assignment 

4.3. 1  D-  or  E-channel 
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Time  slot  24  is  assigned  to  the  0-channel  or  E-channel  when  either  of 
these  channels  is  present. 

4.3,2  B-channel 


One  time  slot  from  the  set  of  time  slots  1  to  23  may  be  assigned  to 
form  each  B-channel.  If  neither  the  D-channel  nor  the  E-channel  is  present, 
time  slot  24  may  be  assigned  to  a  B-channel. 


4.3.3  H„-channel 


Six  time  slots,  1  to  6,  7  to  12  or  13  to  18  are  assigned  to  form  each 
H0-channe1.  The  six  time  slots  19  to  24  are  assigned  to  form  an 
H0-channe1  if  neither  the  D-channel  nor  the  E-channel  is  present. 

4.3.4  B-  and  Hn-channe1s 

When  B-  and  H0-channe1s  are  present  simultaneously  on  the  same 
primary  rate  interface,  two  approaches  are  identified.  The  first  utilizes 
assignment  of  H0-channe1s  as  in  section  4.3.3,  and  permits  allocation  of 
unused  time  slots  for  B-channels.  The  second  permits  a  completely  flexible 
assignment  of  time  slots  to  form  B-  and  H0-channels.  Both  approaches  are 
for  further  study. 

4.3.5  H^-channel 

For  an  Hj-channel  bit  rate  of  1536  kbit/s,  time  slots  1  through  24 
are  assigned  to  one  Hi-channel. 

4.3.6  Other  channels 


For  further  study. 


Timing  considerations 


This  section  describes  the  hierarchical  synchronization  method 
selected  for  synchronizing  ISDNs.  It  is  based  upon  consideration  of 
satisfactory  customer  services,  ease  of  maintenance,  administration  and 
minimizing  cost. 


4.4.1  The  NT  derives  its  timing  from  the  network  clock.  The  TE 
synchronizes  its  timing  (bit,  octet,  framing)  from  the  signal  received  from 
the  NT  and  synchronizes  accordingly  its  transmitted  signal. 

4.4.2  Timing  signals  provide  a  co-directional  interface. 


4.5  Interface  procedures 

4.5.1  Idle  channel  code  (for  further  study) 

4.5.2  Maintenance  (for  further  study) 

4.5.3. 1  Out  of  frame  detection 


A  reframe  procedure  must  start  when  the  fraction  of  the  framing  bits 
in  error  is  in  the  range  from  2  out  of  5  to  2  out  of  4. 


4. 5. 3.2  False  framing 
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The  framing  strategy  must  be  such  that  channel  framing  should  not  falsely 
lock  on  the  signalling  framing. 

4. 5. 3- 3  Reframe  duration 

Maximum  average  reframe  time  shall  be  less  than  40  milliseconds  in  the 
absence  of  errors  (maximum  average  reframe  time  is  the  average  time  to  reframe  when 
the  maximum  number  of  bit  positions  must  be  examined  for  the  framing  pattern) . 

Note  -  This  section  (-4 . 4~3 )  specifies  terminal  equipment,  not  the  interface.  Hence, 
consideration  should  be  given  to  locating  it  elsewhere.  (This  Note  is  to  be 
removed  in  final  drafting.) 

5.  Interface  at  2048  kbit/s 

5.1  Electrical  characteristics 

This  interface  should  conform  to  Recommendation  G.703,  section  6,  which 
recommends  the  basic  electrical  characteristics. 
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5.2 

Frame  structure 

5.2.1 

Number  of  bits  Der  time  slot 

m 

5.2.2 

Eight,  numbered  from  1  to  8. 

Number  of  time  slots  Der  frame 

Thirty- two,  numbered  from  0  to  31 
and  the  frame  repetition  rate  is  8  000  Hz. 

5.2.3 


Frame  alignment  signal 


The  frame  alignment  signal  occupies  positions  2  to  8  in  channel  time  slot  0 
of  every  other  frame  (see  Table  2/1.432). 

The  frame  alignment  signal  is  :  0011011. 

In  order  to  avoid  simulation  of  the  frame  alignment  signal  by  bits  2  to  8 
of  channel  time  slot  0  in  frames  not  containing  the  frame  alignment  signal,  bit  2 
in  those  channel  time  slots  is  fixed  at  1. 

5.2.4  Time  slot  assignment 

5. 2. 4*1  Frame  alignment  signal 

Time  slot  0  is  assigned  to  frame  alignment  in  accordance  with  paragraph  5.2.3. 
5. 2. 4. 2  D-  or  E- channel 

Time  slot  16  is  assigned  to  the  D-channel  or  E-channel  when  either  of  these 
channels  is  present.  The  assignment  of  time  slot  16  when  not  used  for  a  D-  or 
E-channel  is  for  further  study. 


5. 2. 4. 3  B-channel 


Time  slots  1  to  15  and  17  to  31  are  assigned  to  30  B-channels  numbered 
from  1  to  30. 

5. 2. 4. 4  H0-channel 

The  time  slot  assignment  for  the  H0-channel  is  shown  in  Table  3/1.432. 

5. 2. 4. 5  B-  and  H0-channels 

When  B-  and  H0-channels  are  present  simultaneously  on  the  same  primary 
rate  interface,  two  approaches  are  identified. 

The  first  utilizes  assignment  of  H0-channels  as  in  5. 2. 4. 4  and  permits 
allocation  of  unused  time  slots  for  B-channels. 


The  second  permits  a  completely  flexible  assignment  of  time  slots  to  form 
B-  and  H0-channels.  Both  approaches  are  for  further  study. 

5. 2. 4. 6  H^-channel 

Time  slots  1  to  15  and  17  to  31  are  assigned  to  one  H-j-channel  at  1920 

kbit/s. 

5. 2. 4. 7  Other  channels  (for  further  study) 

5.3  Timing  considerations 

This  section  describes  the  hierarchical  synchronization  method  selectedfor 

synchronizing  ISONs.  It  is  based  upon  consideration  of  statisfactory  customer 
service,  ease  of  maintenance,  administration  and  minimizing  cost. 

5.3.1  The  NT  derives  its  timing  from  the  network  clock.  The  TE  synchronizes  its 
timing  (bit,  octet,  framing)  from  the  signal  received  from  the  NT  and  synchronizes 
accordingly  its  transmitted  signal. 

5.4  Interface  procedures 

5.4.1  Idle  channel  code  (for  further  study) 

5.4.2  Maintenance  (for  further  study) 

5.4.3  Frame  alignment  procedures 

Frame  alignment  will  be  assumed  to  have  been  lost  when  three  or  four 
consecutive  frame  alignment  signals  have  been  received  with  an  error. 

Frame  alignment  will  be  assumed  to  have  been  recovered  when  the  following 
sequence  is  detected  : 

for  the  first  time,  the  presence  of  the  correct  frame  alignment  signal; 

the  absence  of  the  frame  alignment  signal  in  the  following  frame  detected 
by  verifying  that  bit  2  in  channel  time  slot  0  is  a  1; 

for  the  second  time,  the  presence  of  the  correct  frame  alignment  signal  in 
the  next  frame. 
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Note  1  -  To  avoid  the  possibility  of  a  state  in  which  no  frame  alignment  can  be 
achieved  due  to  the  presence  of  an  imitative  frame  alignment  signal  the  following 
procedure  may  be  used  : 

When  a  valid  frame  alignment  signal  is  detected  in  frame  n,  a  check  should 
be  made  to  ensure  that  a  frame  alignment  signal  does  not  exist  in  frame  n  +  1,  and 
also  that  a  frame  alignment  signal  exists  in  frame  n  +  2.  Failure  to  meet  one  or 
both  of  these  requirements  should  cause  a  new  search  to  be  initiated  in  frame  n  +  2. 

Note  2  -  It  is  intended  that  this  frame  alignment  procedure  will  be  revised  to  be 
in  accordance  with  relevant  amendments  adopted  under  Q.18/XVIII. 

6.  Mechanical 

To  be  specified. 

6.1  Connector 


For  further  study. 

Connection  to  the  primary  rate  interface  should  be  made  via  a  suitable 
connector.  The  following  are  preliminary  requirements  to  facilitate  selection  of 
a  connector. 

The  connector  should  be  s 

-  rugged; 

-  positive  latching; 

-  self-orienting; 

-  common  to  all  primary  rate  applications; 

-  suitable  for  use  at  speeds  of  1544/2048  kbit/s. 
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CRC-6  Block  Check  Field  (cheek  bits  -  eg) 
The  use  of  the  m-bits  is  for  further  study 
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General 


1.1  Scope  and  field  of  application 

This  Recommendation  defines  the  frame  structure,  elements  of 
procedure  and  procedures  for  the  proper  operation  of  the  Link  Access  Procedure 
on  the  D-channel,  LAPD.  The  application  of  this  protocol  to  other  channel  types 
is  for  further  study. 

The  purpose  of  LAPD  is  to  convey  information  between  iayer  3 
entities  across  the  ISDN  user-network  interface  using  the  D-channel. 

The  definition  of  LAPD  uses  the  principles  and  terminology  of  : 

-  CCITT  Recommendation  X.200  £\J  and  X.210  /”2_7  -  the  reference  model 
for  Open  Systems  Interconnection  (OSI); 

-  CCITT  Recommendation  X.25  £"ij  LAPB  -  user-network  interface  for  packet 
mode  terminals; 

-  ISO  3309  £ 4_7  and  ISO  4335  /  5_7~  high-level  data  link  control  (HDLC) 
standards  for  frame  structure  and  elements  of  procedures. 

LAPD  is  a  protocol  that  operates  at  the  data  link  layer  of  the  OSI 
architecture.  The  relationship  between  the  data  link  layer  and  other  protocol 
layers  is  defined  in  Recommendation  1.311  £  • 

Note  1  -  The  physical  layer  is  defined  in  Recommendation  1-431  /~7_7and 
1.432  /~8_7and  the  layer  3  is  defined  in  Recommendation  Q.93C  (1.451)  Z"9_7- 
Reference  should  be  made  to  these  Recommendations  for  the  complete  definition 
of  the  protocols  and  procedures  across  the  ISDN  user-network  interface. 

Note  2  -  The  term  "data  link  layer"  is  used  in  the  main  text  of  this  Recommendation. 
However,  mainly  in  figures  and  tables,  the  terms  "layer  2"  and  "L2"  are  used 
as  abbreviations.  Furthermore,  in  accordance  with  Recommendations  Q.929  (1.450)  £ 10_7 
and  Q.930  (1.451)  /~9_7»  and  term  "layer  3"  is  used  to  indicate  the  layer  above 
the  data  link  layer. 

IATO  ia  independent  of  tranami ssior  bit  rate.  It  requires  a  full 
duplex,  bit  transparent  D-channel. 

TSie  characteristics  of  the  D-channel  are  defined  in 
Recommendation  1.412. 

Section  1.2  below  describes  basic  concepts  used  in  this 
Recommendation. 
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Section  1.3  gives  an  overview  description  of  LAPD  functions  and 
procedures. 

Section  1.4  summarizes  the  services  that  the  data  link  layer  provides 
to  layer  3  and  the  services  that  the  data  link  layer  requires  from 

the  physical  layer. 

Section  1.5  provides  an  overview  over  the  data  link  layer  structure. 


Concepts  and  terminoloc 


The  basic  structuring  technique  in  the  OSI  model  is  layering. 

According  to  this  technique,  ccrm unication  among  application  processes  is 
viewed  as  being  logically  partitioned  into  an  ordered  set  of  layers  represented 
in  a  vertical  sequence  as  shown  in  Figure  1-1/Q.920. 
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Entities  exist  in  each  layer.  Entities  in  the  same  layer  but  in 
different  systems  which  must  exchange  information  to  achieve  a  camion  objective 
are  called  "peer  entities".  Entities  in  adjacent  layers  interact  through  their 
oamon  boundary.  The  services  provided  by  the  data  link  layer  are  the  results 
of  the  services  and  functions  provided  by  both  the  data  link  layer  and  the 
physical  layer. 

A  data  link  layer  service  access  point  (SAP)  is  the  means  fcy  which  the 
data  link  layer  provides  services  to  the  layer  3.  Associated  with  each 
data  link  layer  SAP  are  one  or  more  data  link  connection  endpoint (s).  See 
Figure  1-2/Q.920.  A  data  link  connection  enapoint  is  identified  by  a  data  link 
connection  endpoint  identifier  as  seen  from  the  network  layer  and  by  a 
cats,  link  connection  identifier  (OLCI)  as  seen  from  the  data  link  layer. 


Cooperation  between  data  Unk  layer  entitles  is  governed  by  a 
i -to- peer  protocol  specific  to  the  layer.  In  order  for  information  to  be 
exchanged  between  two  or  more  network  entities,  an  association  must  be 
established  in  the  data  link  layer.  This  association  is  called  a  data  link 
connection.  Data  link  connections  are  provided  by  the  data  link  layer 
between  two  or  more  SAPs  (see  Figure  1-3/Q.920). 


Service  access  point 


Connection  endpoint 
data  link  connection 
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Data  link  layer  message  units  are  conveyed  between  data  link  layer 
entities  by  means  of  a  physical  connection. 

Hie  network  layer  requests  services  from  the  data  link  layer  via 
service  primitives.  The  sane  applies  for  the  interaction  between  the  data  link 
layer  and  the  physical  layer.  Hie  primitives  represent,  in  an  abstract  way,  the 
logical  exchange  of  information  and  control  between  the  data  link  layer  and 
adjacent  layers.  They  do  not  specify  or  constrain  the  implementation  of 
entities  or  interfaces. 

The  primitives  that  are  exchanged  between  the  data  link  layer  and 
adjacent  layers  are  of  the  following  four  types  (see  also  Figure  1-4/Q-92C)  : 

a)  request; 

b)  indication; 

c)  response; 

d)  confirm. 


Layer  3 


Confirm  — - 


Reouest  Indication  — 


r.e  2  ccr.se 


Data  link  layer 


SAP 


Data  link 


layer  peer-to- 
peer  protocol 

Note  -  The  same  principle  applies  for  data  link  layer  -  physical  layer  interactions. 

FIGCRE  1-4/0.920 
Primitive  action  sequence 


The  REQUEST  primitive  type  is  used  when  a  higher  layer  is 
requesting  a  service  from  the  next  lower  layer. 

The  IfCICATION  primitive  type  is  used  by  a  layer  providing  a  service 
to  notify  the  next  higher  layer  of  activities  related  to  the  primitive  tyre  r^nucst. 

The  RESPONSE  primitive  type  is  used  by  a  layer  to  acknowledge  receipt, 

from  a  lower  layer,  of  the  primitive  type  INDICATION. 


The  OONFIHM  primitive  type  is  used  by  the  layer  providing  the 
requested  service  to  confirm  that  the  activity  has  been  completed . 

Layer-to-layer  interactions  are  specified  in  Section  4. 

Information  is  transferred,  in  various  types  of  message  units,  between 
peer  entities  and  between  entities  in  adjacent  layers  that  are  attached  to  a 
specific  SAP.  The  message  units  are  of  two  types: 

Message  units  of  a  peer-to-peer  protocol. 

Message  units  that  contain  layer-to-layer  information 
concerning  status  and  specialized  service  requests. 

The  message  units  of  the  layer  3  peer-to-peer  protocol  are 
carried  by  the  link  connection.  The  message  units  containing  layer-to-layer 
information  concerning  status  and  specialized  service  requests  are  never 
conveyed  over  a  link  or  a  physical  connection. 

TTiis  Recommendation  specifies  (see  also  Figure  1-5/C-920)  : 

a)  The  peer-to-peer  protocol  for  the  transfer  of  information 

and  control  between  any  pair  of  data  link  layer  service  access 
points. 

b)  The  interactions  tmtwron  the  Data  Link  Layer  and  the  Network 
Layer,  and  between  the  data  link  layer  and  the  physical  layer. 
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1.3  Overview  description  of  LAH)  functions  and  procedures 

1.3.1  General 

The  purpose  of  IATO  is  to  convey  information  between  layer  3 
entities  across  the  ISDN  user-network  interface  using  the  O-channel. 

Specifically ,  LAPD  will  support  : 

-  multiple  -terminal  installations  at  the  user-network 
interface; 

-  multiple  layer  3  entities. 

All  data  link  layer  messages  are  transmitted  in  frames  which  are  delimited 
by  flags.  (A  flag  is  a  unique  bit  pattern.)  (The  frame  structure  is  defined  in 
Section  2). 


IATO  includes  functions  for: 

a)  The  provision  of  one  or  more  data  link  connections  on  a 

D- channel.  Discrimination  between  the  data  link  connections  is  try 
means  of  a  data  link  connection  identifier  (DLCI)  contained  in 
each  frame; 

b)  frame  delimiting,  alignment  and  transparency,  allowing 
recognition  of  a  sequence  of  bits  transmitted  over  a  D- channel 
as  a  frame; 

c)  sequence  oontrol,  to  maintain  the  sequential  order  of  frames 
across  a  data  link  connection; 

d)  detection  of  transmission,  format  and  operational  errors  on 
a  data  link; 

e)  recovery  from  detected  transmission,  format  and  operational 
errors  and  notification  to  layer  3  of  unrecoverable  errors;  . 

f)  flow  oontrol. 

Data  link  layer  functions  provide  the  means  for  information  exchange 
between  multiple  combinations  of  link  endpoints.  The  information  transfer  may 
be  via  point-to-point  links  or  via  broadcast  links.  In  the  case  of 
point-to-point  information  transfer,  a  frame  is  directed  to  a  single  endpoint 
while  in  the  case  of  broadcast  information  transfer  a  frame  is  directed  towards 
one  or  more  endpoints. 

Figure  1-6/Q.920  shows  two  examples  of  point-to-point  information  transfer 
and  Figure  1-7/Q.920  shows  an  example  of  broadcast  information  transfer. 
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Two  types  of  operation  of  the  data  link  layer  are  defined  for 
layer  3  information  transfer  :  unacknowledged ,  and  acknowledged.  They 
may  ooexist  on  a  single  D- channel. 


1.3.2  Unacknowlc 


eration 


With  this  type  of  operation  layer  3  information  is 
transmitted  in  unmsntered  information  (UI)  frames. 


At  the  data  link  layer  the  UI  framfes  are  not  acknowledged. 
Transmission  and  format  errors  may  be  detected  but  no  error  recovery  mechanise 
is  defined.  Flow  control  mechanisms  are  not  defined. 


Unacknowledged  operation  is  applicable  for  point-to-point  and 
broadcast  information  transfer;  e.g.  an  information  frame  may  be  sent  to  a 
specific  endpoint  or  be  broadcast  to  multiple  endpoints  associated  with  a 
Specific  service-access-point  indentifier  (SAPI). 


1.3.3 


Acknowle 


station 


With  this  type  of  operation,  layer  3  information  is  sent  in 
frames  that  are  acknowledged  at  the  data  link  layer. 


Error  recovery  procedures  based  on  retransmission  of  unacknowledged 
frames  ate  specified.  In  the  case  of  errors  which  cannot  be  corrected  by  the 

data  link  layer,  a  report  to  the  layer  3  is  made.  Flow  control  procedures 

are  also  defined. 


transfer. 


Acknowledged  operation  is  applicable  for  point-to-point  information 


Two  forms  of  acknowledged  information  transfer  are  defined, 
a)  single  frame  operation ; 


b)  multiple  frame  operation. 


In  the  case  of  single  frame  operation,  layer  3  information  is  sent  in 
"To  Be  Named"  (TEN r frames ,  using  the  P/F  bit  as  a  modulo  sequence  number.  No  frame 
is  sent  until  an  aknowledgement  has  been  received  for  a  previously  sent  frame;  i.e., 
only  one  frame  may  be  outstanding  at  the  same  time. 


In  the  case  of  multiple  frame  operation,  layer  3  information  is  sent  in 
numbered  information  (I)  frames.  A  number  of  I  frames  may  be  outstanding  at  the 
same  time.  Multiple  frame  operation  is  initiated  by  a  multiple  frame  establishment 
procedure  using  Set  Asynchronous  Balanced  Mode/Set  Asynchronous  Balanced  Mode 
Extended  (SABM/SABME)  commands.  See  section  5.6.1. 


Note  1  -  The  provision  of  extended  multiple  frame  operation  (modulo  128  sequence 
numbering)  is  provisional  and  may  not  be  supported  by  every  network. 


Note  2  -  Urgent  further  study  is  needed  on  the  acknowledged  single  frame  operation 
and  its  need  beyond  an  interim  period. 


The  name  to  be  determined  later. 
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Establishment  of  Information  transfer  modes 
1.3. 4.1  Data  link  connection  identification 

A  data  link  connection  is  identified  by  a  data  link  connection  identifier 
carried  in  the  address  field  of  each  frame. 

The  data  link  connection  identifier  is  associated  with  a  connection  endpoint 
identifier  at  the  two  ends  of  the  link  (see  Figure  1-8/Q.920).  The  connection  endpoint 
identifier  is  used  to  identify  message  units  passed  between  the  data  link  layer  and 
layer  3.  The  data  link  connection  identifier  consists  of  two  elements  :  the  service 
access,  point  identifier  (SAPI)  and  the  terminal  endpoint  identifier  (TEI). 

The  SAPI  is  used  to  identify  the  service  access  point  in  the  network 
or  the  user. 

The  TEI  is  used  to  identify  a  specific  connection  endpoint  within  a 
service  access  point. 

The  TEI  may  be  assigned  automatically  by  means  of  a  separate  TEI  assignment 
procedure  (see  section  1. 3*4*3 )  or  it  may  be  assigned  at  the  time  of  subscription 
and  may  be  entered  into  the  user  equipment;  e.g.,  by  the  subscriber  of  the 
manufacturer. 

In  the  latter  case,  the  TEI  value  must  be  verified  to  ensure  that  the  TEI 
is  not  already  used  by  another  user  equipment.  This  verification  is  performed 
making  use  of  the  same  procedure  used  for  TEI  assignment. 

1.3* 4. 2  Link  states 


A  point-to-point  data  link  may  be  in  one  of  four  basic  states,  see 
Figure  1-9/0.920.  : 

i)  TEI  unassigned  state.  In  this  state  a  TEI  has  not  been  assigned  or 
verified.  No  Information  transfer  is  possible. 

ii)  TEI  assigned  state.  In  this  state  a  TEI  has  been  assigned/verified  by 
means  of  the  TEI  assignment  procedure.  Unacknowledged  information 
transfer  is  possible. 

iii)  Single-frame-established-state.  Acknowledged  single  frame  and 
unaoknowl edged  information  transfer  is  possible. 

iv)  Multiple-frame- established -state.  This  state  is  established  by  means 
of  a  multiple  frame  establishment  procedure.  Acknowledged  multiple 
frame  and  unacknowledged  information  transfer  is  possible. 

A  broadcast  link  is  always  In  an  information  transfer  Btate  capable 
of  unacknowledged  information  transfer. 
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1.3. 4. 3  Automatic  TEI  assignment  procedure 

The  purpose  of  this  procedure  is  to  : 

a)  allow  a  user  equipment  to  request  the  network  to  send  a  TEI  value  that 
data  link  layer  entities  within  the  requesting  user  equipment  will  use 
in  subsequent  communications  over  the  data  link; 

b)  allow  a  user  equipment  to  request  the  network  to  verify  a  TEI  value, 
already  present  in  the  user  equipment,  that  data  link  entities  within 
the  requesting  user  equipment  will  use  in  subsequent  communications 
over  the  data  link. 

The  assigned  TEI  value  is  typically  common  to  all  SAPs  (if  more  than  one) 
in  a  user  equipment.  The  procedure  is  conceptually  located  in  the  management  entity. 
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When  a  TFI  has  been  assigned/verified,  the  user  establishes  an  association 
between  the  TEI  and  a  connection  endpoint  suffix  of  each  SAP;  i.e.,  data  link 
connection  identifier  is  associated  with  connection  endpoint  identifier.  In  the 
netv'ork,  the  corresponding  association  is  made  upon  reception  of  the  first  frame 
containing  the  assigned/verified  TEI. 

At  that  point  in  time,  a  point-to-point  data  link  layer  connection  exists. 

The  association  between  the  data  link  connection  identifier  and  connection 
endpoint  identifier  will  be  removed  : 

a)  in  the  network,  on  request  from  layer  3,  or  by  the  data  link  layer  itself; 

b)  in  the  user  on  request  from  the  management  entity;  e.g.,  when  recognizing 
that  the  TEI  value  is  no  longer  valid,  or  by  the  data  link  layer  itself. 

When  in  the  TEI-assigned  state,  the  TEI  assignment  procedure  may  be  used 
to  check  the  status  of  a  TEI;  e.g.,  to  determine  if  a  user  equipment  has  been  discon¬ 
nected  from  an  installation. 

Examples  of  criteria  for  initiation  of  the  TEI  assignment  procedure  and 
for  the  removal  of  TEI  values  are  described  in  section  5-3,  together  with  the 
detailed  specification  of  the  TEI  assignment  procedure. 

Note  -  This  section  is  not  intended  to  provide  a  complete  specification  of  possible 
criteria  for  establishing  and  removing  an  association  between  data  link  connection 
identifier  and  connection  endpoint  identifier. 

1.3. 4. 4  Establishment  of  single  frame  operation 

The  signle  frame  operation  is  established  upon  request  from  the  local 
layer  3  of  upon  receipt  of  a  "To  Be  Named"  frame.  No  explicit  peer-to-peer  procedure 
is  defined  for  this  purpose. 

1.3-4. 5  Establishment  of  multiple  frame_  operation 

Before  point-to-point  multiple  frame  information  transfer  may  start  an 
exchange  of  SABM/SABME  and  Unnumbered  Acknowledgement  (UA)  frames  takes  place. 

The  multiple  frame  establishment  procedure  is  specified  in  detail  in 
section  5-6. 

1 . 4  Service  cha rdctenstics 

1.4.1  General 

The  data  link  layer  provides  services  to  la^er  1  and  utilizes  the 
services  provided  by  the  physical  layer. 

Note  -  Communication  between  different  entities  in  the  OSI  layered  model  makes  use 
of  primitives  to  be  passed  accross  interfaces.  Primitives  represent,  in  an  abstract 
way,  the  logical 'exchange  of  information  and  control  between  the  data  link  and 
adjacent  layers.  They  do  not  specify  or  constrain  the  implementation  of  entities  or 
interfaces . 
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1.4.2 


Services  provided  to  layer 


The  specification  of  the  interactions  with  layer  3  (primitives)  provides 
a  description  of  the  services  that  the  data  link  layer  plus  the  physical  layer  offer 
to  layer  3.  as  viewed  from  layer  3. 


Two  forms  of  information  transfer  services  are  associated  with  layer  3. 
The  first  is  based  on  unacknowledged  information  transfer  at  the  data  link  layer 
while  the  second  service  is  based  on  acknowledged  information  transfer  at  the 
data  link  layer. 


The  data  link  layer  also  provides  administrative  services  to  layer  3  in 
order  to  implement  information  transfer  services.  Layer  3  message  units  are  handled 
according  to  their  respective  layer  3  priority. 


I . 4 . 2 . I  Unacknowledged  information _t ransfer  service 


Note  -  In  this  case  the  information  transfer  is  rot  acknowledged 
at  tlie  data  link  layer.  Acknowledgement  procedures  may  be  provided  at  higher 
layers. 


The  information  transfer  is  via  broadcast  or  point-to-point  links. 


Tfie  characteristics  of  the  unacknowledged  information  transfer  service 
are  summarized  in  the  following: 


provision  of  a  data  link  connection  between  layer  3 
entities  for  unacknowl edged  information  transfer  of 
layer  3  message  units; 


identification  of  .lata  link  connection  endpoints  to  permit  a 
network  layer  entity  to  identify  another  layer  3  entity; 


no  verification  of  message  arrival  within  the  data  link 
1 ayer . 


The  primitives  associated  with  the  unacknowledged  information  transfer 


service  are: 


DL-UNIT  DATA-REQUEST/ INDICATION 


The  DL-UNIT  DATA-REQUEST  primitive  is  used  to  request  that  a  message  unit 
be  sent  using  the  procedures  for  unacknowledged  information  transfer  service; 
DL-UNIT  DATA- INDICATION  indicates  the  arrival  of  a  message  unit. 


1.4. 2. 2  Ackncwle 


information  transfer  services 


frame: 


TWO  modes  of  operation  are  available:  single  frame  and  multiple 


The  characteristics  of  these  services  are  stirmarized  in  the 
following: 


a)  Provision  of  data  link  connection  between  network  layer  entities 
for  acknowledged  transfer  of  layer  3  message  units. 
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b)  Identification  of  data  link  connection  endpoints  to  permit  a  network 
layer  entity  to  identify  another  network  layer  entity. 

In  addition,  the  multiple  frame  operation  offers  the  following  services  : 
multiple  frame  operation  offers  the  following  services 

c)  Sequence  integrity  of  data  link  layer  message  units. 

d)  Notification  to  the  layer  3  of  unrecoverable  errors  detected  by  the 
data  link  layer. 

e)  Flow  control. 

The  primitives  are  : 

a)  Data  transfer 

DL-DATA-REQUEST/ INDI CATION 

The  DL- DATA- REQUEST  primitive  is  used  to  request  that  a  message  unit  be  sent 
using  the  procedures  for  these  services;  DL-DATA-INDICATION  indicates 
the  arrival  of  a  message  unit.  These  primitives  are  used  for  both  single 
•  frame  and  multiple  frame  operations 

b)  Establishment  of  single  or  multiple  frame  operation 

DLr-  ESTABL I  SI  l-RRQU  EST/  INDICATION 

These  primitives  are  used  to  request  and  indicate  the  establishment 
of  either  the  single  frame  or  the  multiple  frame  operation  betueen 
two  service  access  points. 

c)  Termination  of  single  or  multiple  frame  operation 
Dh- RELEASE-REQUEST/ INDICATION 

These  primitives  are  used  to  reijuest  and  indicate  an  attempt  to 
terminate  single  or  multiple  frame  oneration  between  two  service  access  points . 

I . 4 . 2 . 3  Adm inistrative  services 

The  characteristics  of  the  administrative  services  are  sumnarized 
in  the  following: 

a)  assignment  and  removal  of  TEI-values  to  be  used  on  all  point-to-point 
data  link  connections; 


h)  data  link  connection  parameter  passing  between  the  network  and 
the  user. 

Note  -  The  procedures  for  parameter  passing  are  for  further  study. 


Some  of  these  services  are  considered  to  be  conceptually  provided  via  the 
management  entity  within  the  user  or  network.  The  method  of  describing  these 
administrative  functions  uses  service  primitives. 
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Note  _  It  is  recognized  that  the  current  OSI  layered  model  does  not  completely  define 
the  management  entity  and  its  relations  with  layer  entities.  The  use  of  the  term 
"service  primitives"  between  management  entity  and  data  link  layer  entity  is 
provisionally  adopted  in  this  Recommendation  together  with  its  representation 
method  using  "MDL".  The  appropriateness  of  the  name  and  the  representation  method 
is  for  further  study. 

The  primitives  associated  with,  these  services  are  : 

a)  assignment  of  TEI-value 

MDL-ASSI GN-REQUEST/INDI CATION 

These  primitives  are  used  to  convey  a  TEI,  obtained  or  verified  via  the 
automatic  TEI  assignment  procedure  in  the  management  entity,  from  the 
management  entity  to  the  data  link  layer  in  order  that  the  user  data  link 
layer  entities  can  begin  to  communicate  with  the  network  data  link  layer 
entities  using  the  assigned  TEI  value. 

b)  removal  of  TEI-value 

MDL-REMOVE-REQUEST 

These  primitives  are  used  to  convey  a  management  function  request  for 
removal  of  a  TEI  value  that  has  been  previously  assigned  via  the  MDL- 
ASSIGN  primitives. 

1.4.3  Services  required  from  the  physical  layer 

The  services  provided  by  the  physical  layer  are  described  in  detail  in 
Recommendation  1.431  £ 7_7  or  1.432  £ 8_7.  They  are  summarized  in  the  following  : 

a)  physical  layer  connection  for  the  transparent  transmission 
of  bits  in  the  same  order  in  which  they  are  subnitted  to  the 
physical  layer; 

b)  indication  of  the  physical  status  of  the  D-channel; 

c)  transmission  of  data  link  layer  message  units  according  to 
their  respective  data  link  layer  priority; 

Sane  of  the  above  services  may  be  implemented  via  the  management 
entity  within  the  user  side  or  network  side.  Since  the  CCITT  has  not  defined  these 
Functions,  the  method  of  describing  these  services  is  via  service  primitives. 

The  primitives  associated  between  data  link  layer  and  physical  layer  are: 

a)  Data  transfer 

PIHDATA-RBO IEST/INDICATION 

Ttieso  primitives  are  used  to  request  that  a  message  unit  be  sent 
and  to  indicate  tlie  arrival  of  a  message  unit. 
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b)  PH-ACTIVATE- INDICATION 

This  primitive  is  used  to  indicate  that  the  physical  layer  has  been 
activated . 

c)  PH-DEACTIVATE-INDICATION 

This  primitive  is  used  to  indicate  that  the  physical  layer  has  been 
deactivated . 

Overview  of  data  link  layer  structure 

Figure  1-10/Q.920  is  a  functional  block  diapram  of  the  data  link  layer 
supported  on  a  single  D-channel  that  could  exist  on  the  network. 

The  user  configuration  may  be  a  subset  of  this  figure. 

Figure  1-10/0.920  illustrates  two  procedural  types  :  the  link  procedure 
and  the  multiplex  pi<x»dure. 
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FIGURE  1-10/Q.920 

Functional  block  diagram  of  data  link  layer 


Data  link  layer 
Physical  layer 
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1.5.1 


rooedure 


This  procedure  analyses  the  oontrol  field  of  the  received  frame 
(see  Section  2)  and  provides  appropriate  peer-to-peer  responses  and 
layer- to-layer  indications.  In  addition,  it  analyses  the  data  link  layer 
service  primitives  and  transmits  the  appropriate  peer-to-peer  ccmnands  and 
responses. 

1.5.2  Multiplex  procedure 

This  procedure  analyses  the  flag,  Frame  check  sequence  (FCS),  and  address 
octets  of  a  received  frame.  If  the  frame  is  correct,  it  distributes  the  frame  to 
the  appropriate  link  procedural  Hock  based  on  the  data  link  connection  identifier 
(see  sections  2.3  and  3*2). 

On  frame  transmission,  this  procedure  may  provide  data  link  layer  contention 
resolution  between  the  various  link  procedure  blocks  based  on  the  SAPI,  giving 
priority  to  signalling  information. 


1.5.3 


Structure  of  link  procedure 


The  functional  model  of  the  link  procedure  is  shown  in  Figure  1-11/Q.920. 
The  model  consists  of  several  functional  blocks  for  point-to-point  and  broadcast 
connections.  Each  of  these  functional  blocks  consists  of  three  functional  entities, 
namely  a  transmission  control,  a  reception  control  and  a  link  state  control. 
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FIGURE  1-11/0.920 


2. 


Frame  structure  for  peer-to-peer  common! nation 


2.1  Gent  ral 

All  data  link  layer  peer-to-peer  exchanges  are  in  frames  conforming  to  one  of 
the  formats  shown  in  Figure  2-1/Q.920.  Two  formats  are  shown  in  the  figure,  Format  A 
for  frames  where  there  is  no  information  field,  and  Format  B  for  frames  containing  an 
information  field. 

2.2  Flag  sequence 

All  frames  shall  start  and  end  with  the  flag  sequence  consisting  of  one  "0" 
followed  by  six  contiguous  "l"s  and  one  "0”.  The  flag  preceding  the  address  field  ir 
defined  as  the  opening  flag.  The  flag  following  the  FCS  field  is  defined  as  the  closing 
flag. 

2.3  Address  field 


The  address  field  shall  consist  of  two  octets  as  illustrated  in 
Figure  2-1/Q.920.  The  format  of  the  address  field  is  defined  in  section  3.2.  Single 
octet  address  field  is  reserved  for  LAPB  operation  /_3  J . 

2.4  Control  field 


The  control  field  shall  consist  of  one  or  two  octets.  Figure  2-1/Q.92'1 
illustrates  two  frame  formats,  each  with  the  control  field  of  one  or  two  octets. 

The  format  of  the  control  field  is  defined  in  section  3.4. 

2.5  Information  field 

The  contents  of  the  information  field  shall  consist  of  an  integer  number  of 

octets . 

The  maximum  number  of  octets  in  the  information  field  is  defined  in 
section  5.10.3. 

2 .6  Transparency 

A  transmitting  data  link  layer  entity  shall  examine  the  frame  content 
between  the  opening  and  closing  flag  sequences,  (address,  control,  information  and 
FCS  fields)  and  shall  insert  a  "0"  bit  after  all  sequences  of  five  contiguous  "1” 
bits  (including  the  last  five  bits  of  the  FCS)  to  ensure  that  a  flag  or  an  abort 
sequence  is  not  simulated  within  the  frame.  A  receiving  data  link  layer  entity  shall 
examine  the  frame  contents  between  the  opening  and  closing  flag  sequences  and  shall 
discard  any  "0"  bit  which  directly  follows  five  contiguous  "1"  bits. 
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2.7  Frame  Checking  Sequence  (FCS) 

The  FCS  shall  be  a  sixteen-bit  sequence.  It  shall  be  the  ones  complement  of 
the  sum  (modulo  2)  of  : 

a)  The  remainder  of  (x  raised  to  k  power)  (x5*  ex**  ♦  x**  ♦  x‘* 

♦  x“  ♦  x:*  •*  x*  ♦  x*  ♦  x’  ♦  x*  ♦  x*  ♦  x*  ♦  x*  ♦  x*  ♦  x‘  +\) 
divided  (modulo  2)  by  the  generator  poly nominal  x1*  ♦  x**  ♦ 
x*  ♦  t,  where  k  is  the  number  of  bits  in  the  frame  existing 
between,  but  not  including,  the  ffnal  bit  of  the  opening  flag 
and  the  first  bit  of  the  FCS,  excluding  bits  inserted  for 
transparency,  and 

b)  the  remainder  after  multiplication  by  x16  and  then  division 

(modulo  2)  by  the  generator  polynominal  x“  ♦  x* *  *  x*  ♦  1 , 
of  the  content  of  the  frame,  existing  between  but  not 
including,  the  final  bit  of  the  opening  flag  and  the  first 
bit  of  the  FCS,  excluding  bits  inserted  for  transparency. 

As  a  typical  implementation,  at  the  transmitter,  the  initial 
remainder  of  the  division  is  preset  to  all  "!"s  and  is  then 
modified  by  division  by  the  generator  polynominal  (as  described 
above)  on  the  address,  control  and  information  fields;  the  *M"s 
complement  of  the  resulting  remainder  is  transmitted  as  the 
sixteen-bit  FCS  sequence. 

As  a  typical  implementation  at  the  receiver,  the  initial  remainder 
is  preset  to  all  "1"s.  The  final  remainder  after  multiplication  by 

x:*  and  division  (modulus  2)  by  the  generator  polynominal  x‘*  ♦  x: 1 
♦  x*  *  1  of  the  serial  incoming  protected  bits,  will  be 
OOOH 101000011 n  (x‘*  through  x*.  respectively)  in  the  absence  of 
transmission  errors. 


Format  convention 


2.8.1 


Numbering  convention 


The  basic  convention  used  In  this  Recommendation  is  illustrated  In 
Figure  2-2/Q.920.  The  bits  are  grouped  into  octets.  The  bits  of  an  octet  are  shown 
horizontally  and  are  numbered  from  1  to  8.  Multiple  octets  are  shown  vertically  and 
are  numbered  from  1  to  n. 

Bit  numbering 


2  1 


Octet  1 


Octet 

numbering 


FI GORE  2-2/Q.92Q 
Format  convention 


2.8.2 


Order  of  bit  transmission 


The  octets  are  transmitted  in  ascending  numerical  order; 
bit  1  is  the  first  bit  to  be  transmitted. 


inside  an  octet 


2.8.3 


convention 


When  a  field  is  contained  within  a  single  octet,  the  lowest  bit  number  of 
the  field  represents  the  lowest  order  value. 


When  a  field  spans  more  than  one  octet,  the  order  of  bit  values  progressively 
decreases  as  the  octet  number  increases  within  each  octet.  The  lowest  bit  number 
associated  with  the  field  represents  the  lower  order  value. 


For  example,  a  bit  number  can  be  identified  as  a  couple  (o,  b)  where  o  is 
the  octet  number  and  b  is  the  relative  bit  number  within  the  octet.  Figure  2-3/Q-920 
illustrates  a  field  that  spans  from  bit  (1,  3)  to  bit  (2,  7).  The  high  order  bit  of 
the  field  is  mapped  on  bit  (1,  3)  and  the  low  order  bit  is  mapped  on  bit  (2,  7). 
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Field  mapping  convention 


An  exception  to  the  preceding  field  mapping  convention  is  the  data  link 
layer  Frame  Check  Sequence  (FCS)  field,  which  spans  two  octets.  In  this  case,  bit  1 
of  the  first  octet  is  the  high  order  bit  and  bit  8  of  the  second  octet  is  the  low 
order  bit  (Figure  2- 4/0.920). 
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FCS  mapping  convention 
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SAPI 

C/R 

EA 

0 

Octet  2 

T  E  I 

EA 

1 

3 

EA  =  Extended  address  field  bit 
C/R  =  Command  response  field  bit 
SAPI  =  Service  access  point  identifier 
TEI  =  Terminal  endpoint  identifier 


Note  -  Single  octet  address  field  is  reserved  for  LAPB  operation. 


FIGURE  3-1/0,920 
Address  field  format 


3.3  Address  field  variables 

3*3.1  Extended  address  field  bit  (EA) 

The  address  field  range  is  extended  by  reserving  the  first  transmitted  bit  of 
the  address  field  octets  to  indicate  the  final  octet  of  the  address  field.  The  presence 
of  a  "1"  in  the  first  bit  of  an  address  field  octet  signals  that  it  is  the  final  octet 
of  the  address  field.  The  double  octet  address  field  for  LAPD  operation  shall  have 
bit  1  of  the  first  octet  set  to  a  "0"  and  bit  1  of  the  second  address  octet  set  to  "1”. 


3.3.2 


Command/Response  field  bit  (C/R) 


The  C/R  bit  identifies  a  frame  as  either  a  command  or  a  response.  The  user 
will  send  commands  with  the  C/R  bit  set  to  "0",  and  responses  with  the  C/R  bit  set  to 
"1".  The  network  will  do  the  opposite;  i.e. ,  commands  are  sent  with  C/R  set  to  "1", 
and  responses  are  sent  with  C/R  set  to  "0".  The  combinations  for  the  network  and  user 
are  shown  in  Figure  3-2/Q.920. 
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In  conformance  to  HDLC  rules,  commands  use  the  other  station's  address  while 
responses  use  own  station's  addresses.  According  to  these  rules,  the  addresses  of  the 
network  and  user  side  take  the  form  : 


Network  0  X  Y 

User  1  X  Y 

* 

where  X  and  Y  conform  to  the  definition  contained  in  sections  3.3.3  and  3.3.4. 


3.3.3 


Service  access  point  identifiers 


The  service  access  point  identifier  (SAPI)  specifies  a  data  link  layer  entity 
that  should  process  a  data  link  layer  frame.  The  SAPI  allows  one  of  64  service  access 
points  to  be  specified,  where  bit  3  of  the  address  field  is  the  least  significant 
binary  digit  value  and  bit  8  is  the  most  significant.  The  SAPI  values  are  allocated 
as  follows  : 


SAPI 

Value 


32-47 


All  others 


_ Layer  3  entity _ 

Circuit-switched  procedures 
Packet-switched  procedures 
Reserved  for  national  use 
Management  procedures  (see  Note  1) 
Reserved  for  future  standardization 


Note  1  -  Depending  on  the  outcome  of  studies  on  testing  and  maintenance,  a  specific 
SAPI  may  be  allocated  or  an  already  defined  SAPI  may  also  be  used  for  these  functions. 

Note  2  -  Other  layer  3  entity  assignments  are  a  subject  for  further  study. 

3.3*4  Terminal  endpoint  identifier  (TEI) 

The  terminal  endpoint  identifier  (TEI)  for  a  point-to-point  data  link 
connection  may  be  associated  with  a  single  TE.  A  TE  may  contain  one  or  more  TEIs.  The 
TEI  for  a  broadcast  link  is  associated  with  all  user  side  data  link  layer  entities  con¬ 
taining  the  same  SAPI.  The  TEI  subfield  allows  128  values  where  bit  2  of  the  address 
field  octet  containing  the  TEI  is  the  least  significant  binary  digit  and  bit  8  is  the 
most  significant  binary  digit  value.  The  following  conventions  shall  apply  in  the 
assignment  of  these  values. 

3. 3.4.1  TEI  for  broadcast  data  link  connection 

The  TEI  subfield  bit  pattern  "111  1111"  (binary  value  =  127)  is  defined  as 
the  group  TEI.  The  group  TEI  is  assigned  to  the  broadcast  data  link  connection 
associated  with  the  addressed  SAP. 
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Control  field  bits 
(modulo  8) 


Control  field  formats 


3.5.1 


Modulus 


Each  I  frame  la  sequentially  numbered  and  nay  have  the  value  0  through  "n" 
minus  1  (where  "n"  Is  the  modulus  of  the  sequence  numbers).  The  modulus  equals  8  or 
128  and  the  sequence  numbers  cycle  through  the  entire  range,  0  through  7  or  through  127. 

I 

3.5.2  Multiple  fraae  operation  -  variables  and  sequence  numbers 

3. 5. 2.1  Poll/Final  bit 

The  Poll/Final  (F/F)  bit  serves  a  function  in  both  command  frames  and  response 
frames.  In  command  frames  the  P/F  bit  is  referred  to  as  the  P  bit.  In  response  frames 
it  is  referred  to  as  the  F  bit. 

The  use  of  the  P/F  bit  is  described  in  the  procedure  for  use  of  the  P/F  bit 
in  sections  5.1  mad  5.6. 

3. 5. 2. 2  Send  state  variable  V(S) 

Each  point-to-point  data  link  connection  endpoint  shall  have  an  associated 
send  state  variable  (V(S))  when  using  commands/responses  contained  in  the  I  and  S 
frames.  The  send  state  variable  denotes  the  sequence  number  of  the  next  in-sequence  I 
frame  to  be  transmitted  or  re-transmitted.  The  send  state  variable  can  take  on  the 
value  0  through  modulus  minus  1.  The  value  of  the  send  state  variable  shall  be  incre¬ 
mented  by  1  with  each  successive  I  frame  transmission  or  re-transmission,  and  shall 
not  exceed  V(A)  by  more  than  the  maximum  number  of  outstanding  I  frames  k.  The  value 
of  k  may  be  in  the  range  of  1  <  k  <  7  for  basic  (modulo  8)  operation  and  1  <  k  <  127 
for  extended  (modulo  128)  operation. 

3. 5.2.3  Acknowledged  state  variable  V(A) 

Each  point-to-point  data  link  connection  endpoint  shall  have  an  associated 
acknowledged  state  variable  (V(A))  when  using  commands/responses  contained  in  the 
I  and  S  frames.  The  acknowledged  state  variable  denotes  the  last  frame  that  has  been 
acknowledged  by  its  peer  (T(A)-l  equals  the  N(S)  of  last  acknowledged  frame).  The 
acknowledged  state  variable  can  take  on  the  value  0  through  modulus  ainUb  1.  The  value 
of  the  acknowledged  state  variable  shall  be  updated  by  the  valid  N(R)  values  received 
from  its  peer  (see  section  3*5. 2. 6).  A  valid  N(R)  value  is  one  that  is  in  the  range 
V(A)  <  N(R)  $  X  (internal  state  variable)  in  the  timer  recovery  condition  (see 
section  5.7.7). 

3. 5> 2.4  Send  sequence  number  NtS) 

Only  I  frames  contain  H(S),  the  send  sequence  number  of  transmitted  I  frames. 
Prior  to  transmission  of  an  in-sequence  I  fraae,  the  value  of  H(S)  is  set  equal  to  the 
value  of  the  send  state  variable  V(S). 

3* 5. 2. 5  Receive  state  variable  V(R) 

Each  point-to-point  data  link  connection  endpoint  shall  have  an  associated 
receive  state  variable  (V(R))  when  using  commands/responses  contained  in  the  I  and  S 
frames.  The  receive  state  variable  denotes  the  sequence  number  of  the  next  ln-sequence 
I  frame  to  be  received.  The  receive  state  variable  can  take  on  the  value  "0"  through 
modulus  minus  1  and  shall  be  incremented  by  one  with  the  receipt  of  an  error  free, 
ln-sequence  I  fraae  whose  send  sequence  number  N(S)  equals  the  receive  state  variable 
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3. 5. 2. 6  Receive  sequence  number  N(R) 


All  I  end  S  foraat  frames  contain  B(R).  Prior  to  trananiaaion  of  I  or  S 
franca,  the  value  V(R)  is  set  equal  to  the  current  value  of  the  receive  state  variable 
(V(R)).  H(R)  Indicates  that  the  data  link  layer  entity  transmitting  the  N(R)  has 
correctly  received  all  I  fraaes  numbered  up  to  and  including  N(R)  -  1. 


3.5.3 


gle  frame  operation  variables 


3-5.3.1 


Inal  bit 


The  Poll/Tinal  (P/F)  bit  serves  a  function  in  both  conaand  and  response  frames. 
In  conaand  frames  the  P/F  bit  is  referred  to  as  the  P  bit.  In  response  fraaes  it  is 
referred  to  as  the  F  bit. 

3- 5.3.2  Poll  bit  state  variable  V(P) 

Each  point-to-point  data  link  connection  endpoint  shall  have  an  associated 
poll  bit  state  variable  V(P)  when  using  TBN  commands  or  responses  in  single  frame 
operation.  The  poll  bit  state  variable  V(P)  shall  denote  the  value  N(P)  of  the  poll 
bit  in  the  next  in-sequence  TBN  command  frame  to  be  transmitted.  The  value  of  V(P) 
shall  be  complemented  each  time  a  transmitted  TBN  frame  is  correctly  acknowledged.  V(P) 
shall  be  reset  in  accordance  with  the  procedures  defined  in  section  5.5.4. 
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3. 5.3.3  Final  bit  state  variable  V(F) 

Each  point-to-point  data  link  connection  endpoint  shall  have  an  associated 
final  bit  state  variable  V(F)  when  using  TBN  commands  or  responses  in  single  frame 
operation.  The  final  bit  state  variable  V(F)  shall  denote  the  value  N(F)  of  the 
final  bit  in  the  next  TBN  response  frame  to  be  transmitted  to  acknowledge  a  correctly 
received  TBN  command  frame.  If  the  poll  bit  in  the  received  TBN  frame  ia  equal  to  the 
current  value  of  T(F),  the  value  of  the  V(F)  shall  be  complemented.  The  value  of 
V(F)  shall  be  reset  in  accordance  with  the  procedures  defined  in  section  5.5.3* 


The  following  commands  and  responses  are  used  by  either  the  user  or  the  network 
data  link  layer  entities  and  are  represented  in  Figures  3-4/Q.920  and  3-5/Q.920.  Each 
data  link  connection  uses  an  appropriate  subset  of  these  commands  and  responses. 

The  commands  and  responses  are  as  follows  : 

3*6.1  Information  (I)  nd 


The  function  of  the  information  (I)  command  is  to  transfer  across  a  data 
link  connection  sequentially  numbered  frames  containing  information  fields  provided 
by  the  layer  3«  This  command  is  used  in  multiple  frame  operation  on  point-to-point 
data  link  connection. 
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Commands  and  responses  -  extended  (modulo  128)  operation 


3.6.2 


Set  asynchronous  balanced  mode  (SABM)  and  set  asynchronous  balanced  mode 
extended  (SABME)  co""i'*nrig 

The  SABH/SABME  unnumbered  command  is  used  to  place  the  addressed  user  side 
and  the  network  side  data  link  layer  connection  into  multiple  frame  operation. 

No  information  field  is  permitted  with  the  SABM/SABME  commands.  A  data 
link  layer  entity  confirms  acceptance  of  SAB^SABME  by  the  transmission  at  the  first 
opportunity  of  a  UA  response.  Upon  acceptance  of  this  command  the  data  link  layer 
entity's  send  state  variable  V(S),  acknowledged  state  variable  V(A),  and  receive  state 
variable  V(R)  are  set  to  0. 

Previously  transmitted  I  frames  that  are  unacknowledged  when  this  command  is 
actioned  remain  unacknowledged  and  are  not  retransmitted. 

3.6.3  Disconnect  (DISC)  command 

The  DISC  unnumbered  command  shall  be  transmitted  to  terminate  the  multiple 
frame  operation. 

No  information  field  is  permitted  with  the  DISC  command.  Prior  to  actioning 
the  command,  the  data  link  layer  entity  receiving  the  DISC  confirms  the  acceptance  of 
a  DISC  by  the  transmission  of  a  UA  response.  The  data  link  layer  entity  sending  the 
DISC  terminates  the  multiple  frame  operation  when  it  receives  the  acknowledging  UA  or 
DM  response. 

Previously  transmitted  I  frames  that  are  unacknowledged  when  this  command  is 
actioned  remain  unacknowledged  and  are  not  retransmitted  by  the  data  link  layer  entities. 

3.6.4  Unnumbered  information  (UI)  command 

When  a  layer  3  or  management  entity  requests  unacknowledged  information 
transfer,  the  UI  command  shall  be  used  to  send  information  to  its  peer  without  affecting 
data  link  layer  variables.  These  UI  command  frames,  transmitted  via  a  data  link  connec¬ 
tion,  do  not  carry  a  sequence  number;  therefore,  the  UI  frame  may  be  lost  without 
notification  to  layer  3  if  a  data  link  exception  occurs  during  transmission  of  the 
command. 

3.6.5  "To  be  pained11  (TBN)  command 

The  function  of  the  "to  be  named"  (TBN)  command  is  to  transfer  information 
between  data  link  layer  entities  using  sequentially  acknowledged  frames  containing 
information  fields  provided  by  layer  3.  TBN  commands  are  sequence-verified  by  the 
use  of  the  P/F  bit.  This  command  is  used  in  single  frame  operation  on  point-to-point 
data  links.  The  TBN  frame  may  be  lost  without  notification  to  layer  3  if  a  data  link 
exception  condition  occurs  during  transmission  of  the  command,  or  during  a  reply  to 
the  command  when  the  V(P)  and  the  V(F)  variables  are  out  of  step. 

Receive  ready  (RB)  command/response 

The  receive  ready  (RR)  supervisory  frame  is  used  by  a  data  link  layer  entity 


3.6.6 

to  : 


a)  indicate  it  is  ready  to  receive  an  I  frame; 
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b)  acknowledge  previously  received  I  frames  numbered  up  to  and  including 
N(R)  -  1  (as  defined  in  section  5); 

c)  clear  a  busy  condition  that  was  indicated  by  the  previous  transmission  of 
an  RNR  frame. 

t 

In  addition  to  indicating  the  status  of  a  data  link  layer  entity,  the  HR 
command  with  F  bit  set  to  "1"  may  be  used  by  the  data  link  layer  entity  to  ask  for 
the  status  of  its  peer. 

command/res 


The  reject  (REJ)  supervisory  frame  is  used  to  request  retransmission  of  I 
frames  starting  with  the  frame  numbered  N(R).  The  value  of  N(R)  in  the  REJ  frame 
acknowledges  frames  numbered  up  to  and  including  N(R)  -  1.  New  I  frames  pending 
initial  transmission  shall  be  transmitted  following  the  retransmitted  I  frame (s). 

Only  one  REJ  exception  condition  for  a  given  direction  of  information 
transfer  shall  be  established  at  a  time.  The  REJ  exception  condition  is  cleared  (reset) 
upon  the  receipt  of  an  I  frame  with  an  N(S)  equal  to  the  V(R)  of  the  REJ.  The  REJ 
condition  is  also  reset  upon  the  receipt  of  a  mode  setting  command  (SABM/SABME  or 
DISC). 

The  transmission  of  REJ  shall  also  indicate  the  clearance  of  any  busy  condi¬ 
tion  with  the  sending  data  link  layer  entity. 

In  addition  to  indicating  the  status  of  a  data  link  layer  entity,  the  REJ 
command  with  P  bit  set  to  "1"  may  be  used  by  the  data  link  layer  entity  to  ask  for 
the  status  of  its  peer. 

.6.8  Receive  not  ready  (RNR)  command/re scons e 


The  receive  not  ready  (RNR)  supervisory  frame  shall  be  used  by  a  data  link 
layer  entity  in  the  user  side  or  network  side  to  indicate  a  busy  condition;  that  is, 
temporary  inability  to  accept  additional  incoming  I  frames.  The  value  of  N(R)  in  the 
RNR  frame  acknowledges  I  frames  numbered  up  to  and  including  N(R)  -  1.  I  frame  N(R) 
and  subsequent  I  frames  received,  if  any,  are  to  be  acknowledged;  the  acknowledge¬ 
ment  of  these  I  frames  will  be  indicated  in  subsequent  exchanges.  The  data  link  layer 
entity  originating  the  RNR  shall  indicate  the  clearance  of  the  busy  condition  by 
transmission  of  RR.  Alternatively  the  condition  may  be  cleared  by  the  transmission  of 
SABM/SABME,  DA,  or  REJ. 

In  addition  to  indicating  the  status  of  a  data  link  layer  entity,  the  RNR 
command  with  P  bit  set  to  "l"  may  be  used  by  the  data  link  layer  entity  to  ask  for 
the  status  of  its  peer. 


3.6.9 


Unnumbered  acknowledgement  (DA)  response 


The  DA  response  is  used  to  acknowledge  the  receipt  and  acceptance  of  the 
D  format  set  mode  commands  (SABM/SABME  or  DISC).  Received  U  format  set  mode  commands 
are  not  actioned' until  the  DA  response  is  transmitted.  No  information  field  is 
permitted  with  the  UA  response. 
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3.6.10  Disconnected  mode 


response 


The  DM  response  is  used  by  a  data  link  layer  entity  to  report  to  its  peer 
that  the  data  link  layer  is  in  a  state  where  multiple  frame  operation  cannot  be 
performed.  No  information  field  is  permitted  with  the  DM  response.  A  data  link 
layer  entity  shall  transmit  a  DM  response  to  any  command  which  it  cannot  action. 

3.6.11  "To  be  named1'  (TBN)  response 

The  TBN  response  is  used  to  acknowledge  the  receipt  of  a  TBN  command,  when 
the  data  link  connection  is  operating  in  single  frame  operation.  There  is  no  I 
field  contained  in  a  TBN  response. 


3.6.12  Frame  reject 


response 


The  FRMR  response  may  be  used  by  a  data  link  layer  entity,  when  operating  in 
multiple  frame  operation,  to  report  an  error  condition  not  recoverable  by  retrans¬ 
mission  of  the  identical  frame;  that  is,  one  of  the  following  conditions,  which 
results  from  the  receipt  of  a  frame  without  errors  indicated  in  section  2.9  : 

a)  an  error  free  frame  which  is  unknown  as  a  command  or  response; 

b)  an  invalid  frame  format; 

c)  an  invalid  N(R)  condition; 

d)  an  information  field  which  exceeds  the  maximum  information  field  length 
which  can  be  accommodated. 

A  valid  N(R)  value  is  one  that  is  in  the  range  V(A)  <  N(R)  i  V(S)  in  the 
normal  condition  or  frame  rejection  condition  or  V(A)  <  N(R)  $  X  internal  state 
variable  when  in  the  timer  recovery  condition. 

An  information  field  which  immediately  follows  the  control  field  and 
consists  of  three  or  five  octets  (modulo  8  (basic)  operation  or  modulo  128  (extended) 
operation,  respectively),  is  returned  with  this  response  and  provides  the  reason 
for  the  FRMR  response.  This  information  field  format  is  given  in  Figures  3-6/Q.920 
and  3-7/Q.920. 
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Communications  between  layer*  and,  for  thia  recommendation,  between  the 
data  link  layer  and  the  management  entity  are  accomplished  by  means  of  primitives. 

Primitives  represent.  In  an  abstract  way,  the  logical  exchange  of 
Information  and  control  between  the  data  link  and  adjacent  layers.  They  do  not 
specify  or  constrain  the  Implementation  of  entities  or  interfaces. 

Primitives  consist  of  commands  and  their  respective,  responses  associated 
with  the  services  requested  of  a  lower  layer.  The  general  syntax  of  a  primitive  is  : 

g  Generic  name  Type  :  Parameters 

Where  XX  designates  the  layer  providing  the  service.  For  this 

Recommendation  XX  is  either  DL  for  the  data  link  layer,  PH  for  the  physical  layer,  or  MDL 
for  the  management  entity  to  the  data  link  layer  interface. 

Mote. J  -  The  full  definition  as  to  specifying  the  management  entity  to  the  data  link 
layer  interface  is  a  subject  for  further  study. 

Sflte  2  —  For  better  understanding,  the  semantics  of  primitives  will  be  improved  in  the 
next  study  period  (Question  Q/XI). 

4-1.1  Generic  names 

The  generic  name  specifies  the  activity  that  the  addressed  layer  should 
perform.  Tables  1/Q.920  illustrates  the  primitives  defined  in  this  Recommendation. 

Rote  that  not  all  primitives  have  associated  parameters. 

ndatlon  are  : 


The  primitive  generic  names  that  are  defined  in  this  Reci 
4. 1.1*1  DL-ESTABLISH 

The  DL-ESTABLISH  primitives  are  used  to  request  and  indicate  the  out 
of  the  procedures  for  establishing  single  or  multiple  frame  operation. 

4.1. 1.2  DL-RELEASE 

The  DL-RELEASE  primitives  are  used  to  request  and  indicate  the  outcome  of 
the  procedures  for  terminating  a  previously  established  single  or  multiple  frame 
operation.  In  the  case  of  a  data  link  layer  malfunction,  layer  3  will  be  notified 
by  a  RELEASE  indication. 

4.1. 1.3  DL-DATA 

The  DL-DATA  primitives  are  used  to  pass  layer  3  messages  to  and  from 
the  data  link  layer  which  are  to  be  transmitted,  or  have  been  received,  using 
acknowledged  operation. 
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4. 1.1.4  DL-UNIT  DATA 


The  DL-UNIT  DATA  primitives  are  used  to  pass  layer  )  messages  to  and 
from  the  data  link  layer  which  are  to  be  transmitted,  or  have  been  received,  using 
the  unacknowledged  mode  of  information  transfer. 

4.1. 1.5  MDL-ASSIGN 

The  MDL-ASSIGN  primitives  are  used  by  the  management  entity  to  request  that 
the  data  link  layer  associate  the  TGI  contained  within  the  message  portion  of  the 
primitive  with  the  specified  connection  enapoint(s).  The  data  link  layer  indicates 
to  the  management  entity  the  need  for  a  TGI  value. 

4. 1.1.6  MDL -REMOVE 


The  MDL-REMOVE  primitives  are  used  by  the  management  entity  to  request  that 
the  data  link  layer  remove  the  association  of  the  specified  TEI  value  with  the 
specified  connection  endpoints.  The  TEI  and  connection  endpoints  are  specified  by  the 
REMOVE  primitive  message  unit. 

4. 1.1. 7  MDL-ERROR 

The  MDL-ERROR  primitives  are  used  to  notify  the  management  entity  that  an 
error  has  occurred,  associated  with  a  previous  management  function  request  or  detected 
as  a  result  of  communication  with  the  data  link  layer  peer  entity,  which  cannot  be 
corrected  by  the  data  link  layer.  The  management  entity  may  respond  with  an  ERROR 
primitive  if  the  management  entity  cannot  obtain  a  TEI  value. 

4.1. 1.8  MDL- UNIT  DATA 

The  MDL-UNIT  DATA  primitives  are  used  to  pass  management  entity  messages  to 
and  from  the  data  link  layer  which  are  to  be  transmitted,  or  have  been  received,  using 
the  unacknowledged  mode  of  Information  transfer. 

4. 1.1. 9  PH-DATA 

The  PH-DATA  primitives  are  used  to  pass  to  and  receive  from  the  physical 
layer,  message  units  containing  fri  mes  used  for  data  link  layer  peer-to-peer 
communications . 

4.1.1.10  PH-ACTIVATE 

The  PH-ACTIVATE  primitives  are  used  to  indicate  that  the  physical  layer  has 
been  activated.  The  REQUEST  option  is  for  further  study. 

4.1.1.11  PH-DEACTIVATE 

The  PH-DEACTIVATE  primitives  are  used  to  indicate  that  the  physical  layer 
has  been  deactivated.  The  REQUEST  option  is  for  further  study. 

Note  -  The  provision  of  additional  primitives  is  for  further  study. 
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4*1.2  Primitive  types 

The  primitive  types  defined  in  this  Recommendation  are  : 

4.1. 2.1  REQUEST 

The  REQUEST  primitive  type  is  used  when  a  higher  layer  is  requesting  a 
service  from  the  next  lower  layer. 

4. 1.2. 2  INDICATION 

The  INDICATION  primitive  type  is  used  by  a  layer  providing  a 
service  to  notify  the  next  higher  layer  of  activities  related  to 

the  REQUEST  primitive  type. 

4. 1.2. 3  RESPONSE 

The  RESPONSE  primitive  type  is  used  by  a  layer  to  acknowledge 
receipt,  from  a  lower  layer,  of  the  INDICATION  primitive  type. 

4. 1.2. 4  CONFIRM 

The  CONFIRM  primitive  type  is  used  by  the  layer  providing  the 
requested  service  to  confirm  that  the  activity  has  been  completed. 

Figure  4-1/Q.920  illustrates  the  relationship  of  the  primitive 
types  to  the  layer  3  and  data  link  layer. 
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FIGURE  4-1/Q.920 


Relationship  of  the  primitive  types  to  the 
layer  3  and  the  data  link  layer 
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4-1.3  Parameter  definition 
4-1- 3-1  Priority  Indicator 

Since  several  SAPs  may  exist  within  a  network  or  a  user,  protocol 
messages  units  sent  by  one  SAP  may  contend  with  those  of  other  service  access 
points  for  the  physical  resources  available  for  message  transfer.  The  priority 
indicator  is  used  to  determine  which  message  unit  will  have  greater  priority  when 
contention  exists. 


4. 1.3. 2  Message  unit 


The  Message  unit  contains  additional  layer-to-layer  information 
concerning  actions  and  results  associated  with  requests.  In  the 
case  of  the  data  primitive,  the  message  unit  contains  the 
requesting  layer  peer-to-peer  messages.  For  example  DL-DATA 
message  unit  contains  layer  3  information.  The  PN-DATA 
message  unit  contains  the  data  link  frame. 

Note  -  The  operations  across  the  data  link  layer  3  boundary 
shall  be  Buch  that  the  layer  sending  the  DATA  or  UNITDATA  primitive  can 
assume  a  temporal  order  of  the  bits  within  the  message  unit  and  that  the 
layer  receiving  the  primitive  can  reconstruct  the  message  with  its  assumed 
temporal  order. 

4*2  Primitive  procedures 

A  subject  for  further  study. 

5  Definition  of  the  peer-bo-peer  procedures  of  the  data  link  Layer 

The  procedures  for  use  by  the  data  link  layer  are  specified  in  the 
following  sections.  The  need  for  additional  procedure  sets  is  for  further 
study. 

The  elements  of  procedure  (frame  types)  which  apply  are  : 

a)  for  unacknowledged  information  transfer  (section  5.2) 

UI- command 

b)  for  single  frame  acknowledged  information  transfer  (section  5.5) 

T8N- command/ re  spon  se 

c)  for  multiple  frame  acknowledged  information  transfer  (sections  5.6  to  5.10) 

SABM/SABME-command 

DA-response 

DM-responae 

DISC-command 

RR- command/response 

RNR- command/response 

REJ-command/response 

I -command 

FRMR-response . 
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5.1  Procedure  for  the  use  of  the  P/F  bit 

5.1.1  Inmediate  response  operation 

A  data  link  layer  entity  receiving  an  SABI.  SAB ME,  DISC,  RR,  RNR,  or  REJ 
I  frame  with  the  P  bit  set  to  1,  shall  set  the  F  bit  to  1  in  the  next  response 
frame  it  transmits  as  defined  in  Table  5-1/Q. 920  below  : 


TABLE  5-1/Q.920 

Immediate  response  operation  of  P/F  bit 


Command  received 
with  P  bit  «  1 

Response  transmitted 
with  F  bit  -  1 

SABM,  SABME ,  DISC 

UA.DM 

I,  RR,  RNR,  REJ 

RR,  RNR,  REJ,  FRMR,  DM 

3. 1.2  Single  frame  operation 

When  in  the  single  frame  operation  the  bit  provides  a  function  similar 
to  sequence  numbers. 

5.2  Procedures  for  unacknowledged  information  transfer 

5.2.1  General 

The  procedures  which  apply  to  the  transmission  of  information  in 
unacknowledged  operation  are  defined  below. 

No  data  link  layer  error  recovery  procedures  are  defined  for 
unacknowledged  operation. 

5.2.2  Transmission  of  unacknowledged  information 

Unacknowledged  information  is  passed  to  the  data  link  layer  by  layer  3 
using  the  primitive  DL-UNITDATA-REQUEST.  The  layer  3  message  unit  shall  be 
transmitted  in  UI  command  frames. 

For  broadcast  operation,  the  TEI  value  shall  be  set  to  127  (binary  111  1111 
the  group  value). 


For  point-to-point  operation  the  appropriate  TEI  value  shall  be  used. 
The  Poll  bit  shall  be  set  to  binary  "0". 
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5.2.3  Receipt  of  unacknowledged  information 

On  receipt  of  a  01  frame  with  a  SAPI  which  is  supported  by  the  user,  the 
contents  of  the  information  field  shall  be  passed  to  the  layer  3  using  the  data  link 
layer  to  the  layer  3  primitive  DL-UNITDATA-INDICATION.  Otherwise  the  UI  frame  shall 

be  disregarded. 


5.3  Assignment  and  removal  of  terminal  endpoint  identifier  (TEI) 

5-3.1  General 
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A  user  equipment  in  the  TEI-unassigned  state  shall  use  the  TEI 
assignment  procedures  to  enter  the  TEI-assigned  state.  Conceptually  these  procedures 
exist  in  the  management  entity.  The  management  entity  on  network  side  is  referred 
to  as  the  Assignment  Source  Point  (ASP)  in  this  Recommendation. 

The  purpose  of  this  procedure  is  to  : 

a)  allow  a  user  equipment  to  request  the  network  to  select  a  TEI 

value  that  the  data  link  layer  entities  within  the  requesting  user  equipment 
will  use  in  their  subsequent  communications; 

b)  allow  a  user  equipment  to  request  the  network  to  verify  a  TEI  value 
already  present  in  the  user  equipment,  which  the  data  link  layer  entities 
within  the  requesting  user  equipment  will  use  in  their  subsequent 
communications; 

c)  allow  a  network  to  remove  a  previously  assigned  TEI  from  specific  or 
all  user  equipments. 

Additionally,  the  user  management  entity  may  instruct  the  data  link  layer 
entity  to  remove  a  TEI  value  for  its  own  internal  reasons.  The  management  intity 
shall  use  the  MDL-RIMOVE-REQUEST  for  this  purpose.  Conditions  under  which  this  would 
occur  are  for  further  study. 

Note  -  Subject  to  further  study,  internal  reasons  may  include  s 

a)  gaining  or  regaining  the  ability  to  communicate  with  the  network  ; 

b)  initialization  from  a  no-power  condition; 

c)  status  of  the  physical  layer  (or  whether  it  is  plugged  into  or  re-plugged 
into  the  interface) ; 

d)  local  monitoring  or  detection  of  malfunctions; 

e)  others. 

Section  5.3 .4*1  includes  the  actions  taken  by  a  data  link  layer  entity 
receiving  a  MDL-RIMOVE-REQUEST. 
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Typically,  one  TEI  value  would  be  used  by  the  user  equipment  (i.e.  a  data 
link  layer  entity  which  has  been  assigned  a  TEI  value  could  use  that  value  for  all  SAPs 
which  it  supports).  If  required,  a  number  of  TEI  values  may  be  requested  by  multiple 
use  of  the  procedures  defined  in  section  5.3.2.  It  shall  be  the  responsibility  of 
the  user  to  maintain  the  association  between  TEI  and  SAPI  values.  ~ 


The  initiation  of  these  procedures  occurs  on  the  receipt  of  DL-ESTABLISH- 
REQUEST  from  the  network  layer  while  in  the  ?EI  unassigned  state.  The  data  link  layer 
entity  shall  inform  the  management  entity  by  using  the  MDL-ASSIGN-INDICATION. 
Alternatively,  the  management  may  initiate  these  procedures  for  its  own  reasons. 


All  management  entity  messages  used  for  these  procedures  are  transmitted 
to,  or  received  from,  the  data  link  layer  entity  using  the  MDL-UNITDATA-REQUEST  or 
INDICATION  respectively. 


The  data  link  layer  entity  shall  transmit  MDL-UNITDATA-MES SAGES  in  UI 
frames.  The  SAPI  value  shall  be  63.  The  TEI  value  shall  be  127. 


5.3.2 


TEI  assignment  procedure 


Upon  initiation  of  the  procedure,  the  management  entity  shall  transmit  a 
message  containing  the  following  elements  : 


a)  Message  type  =  Identity  request 

b)  Request  reference  number  (Ri) 

c)  Action  indicator  (Ai). 


The  Request  reference  number  Ri  shall  be  used  to  differentiate  between 
a  number  of  user  equipments  which  may  simultaneously  request  initialization  of  the 
TEI  value.  Ri  shall  be  2  octets  in  length  and  shall  be  generated  by  the  user 
equipments. 


The  single  octet  Action  indicator  Ai  shall  be  used  to  indicate  a 
request  to  the  Assignment  Source  Point  (ASP)  for  the  assignment  of  eithe.  any  TEI 
value  available,  or  a  preferred  TEI  value. 


The  coding  of  Che  AI  shall  be  as  follows  : 


a)  AI  ■  Croup  address  TEI  (127): 

This  AI  value  requests  the  ASP  to  assign  any  TEI  value. 


b)  AI  ■  Preferred  TEI: 

This  Ai  value  requescs  the  ASP  to  verify  the  preferred  TEI  value 


A  timer  T202  shall  be  started. 


The  ASP,  on  receipt  of  the  Identity  request  message  shall  either  : 


a)  select  and  verify  a  TEI  value  if  no  preferred  value  was  indicated;  or, 


b)  verify  the  indicated  preferred  value. 


>VVv\ 
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Verification  shall  be  on  the  basis  of  information  stored  at  the  ASP  and/or  by 
means  of  the  check  routines  defined  in  section  5.3.3. 

The  ASP,  after  having  selected/verified  the  TEI  value,  shall  transmit  a  message 
containing  the  following  elements  : 

a)  Message  type  =  Identity  assigned; 

b)  Request  reference  number  Ri; 

c)  the  assigned  TEI  value  in  the  Ai  field. 

The  user  management  entity  receiving  this  message  shall  inform  the  data 
link  layer  by  means  of  MDL-ASSIGN -REQUEST. 

The  user  data  link  layer  entity  shall  : 

a)  enter  the  TEI  assigned  state; 

b)  set  the  TBN  frame  variables,  V (P)  and  V(F),  if  appropriate; 

c)  continue  with  link  establishment  procedures  if  a  DL-ESTABLI SH-REQUEST  is 

outstanding. 

If  a  TEI  is  not  available  (or  the  preferred  TEI  value  is  not  available),  the 
ASP  shall  transmit  a  message  containing  the  following  elements  : 

a)  Message  type  =  Identity  denied 

b)  Request  reference  number  Ri 

c)  the  value  of  TEI  which  is  denied  in  the  Ai  field  (a  value  of  127  indicates 

that  no  TEIs  are  available). 

The  user  management  entity  receiving  the  Identity  denied  message  may  reinvoke 
the  assignment  procedures  to  obtain  a  TEI  value;  but  otherwise,  the  management  entity 
shall  inform  the  data  link  layer  entity  using  MDL-ERROR-RESPON  SE.  The  data  link  layer 
entity  receiving  MDL-ERROR-RESPON SE  shall  inform  layer  3  using  the  primitive 
DL-RELEASE- INDICATION. 

5.3* 2.1  Expiry  of  Timer  T202 

If  the  user  receives  no  response  to  its  Identity  request  message  within 
T202,  the  timer  shall  be  reset  and  the  Identity  request  message  shall  be  retransmitted. 

After  N202  retransmissions  the  management  entity  shall  inform  the  data  link 
layer  entity  using  MDL-ERROR-RESPONSE.  The  data  link  layer  entity  receiving 
MDL-ERROR-RESPON SE  shall  inform  layer  3  using  the  primitive  DL-RELEASE-INDICATION. 

The  value  of  T202  is  specified  in  section  5.10.6.  The  value  of  N202  is 
for  further  study. 


The  TEI  assignment  procedure  is  illustrated  in  Figure  5-1/Q.920. 
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User  side 


ASP 


start 

T2C2 


[iD  request,  Ai,  Ri]  (SAPI,  TEI) 


01 


****************** 

*  Check  routines,  * 

*  if  applicable  * 


UI  (SAPI,  TEI)  [iD  assigned,  Ri,  Ail 


or 


UI  (SAPI,  TEI)  [ID  denied,  Ri,  Ai) 


- 1 

SAPI  =  Service  access  point  identifier  =  63. 

TEI  =  group  TEI  =  127 

ID  request  =  Identity  request 
ID  denied  =  identity  denied 

Ai  =  action  indicator,  see  Table  5-2/Q.920 

Ri  =  Reference  number 

(  )  =  Contents  of  the  data  link  layer  address  field 

[  j  =  Contents  of  the  Information  field 

FIGURE  5-1/Q.920 

TEI  assignment  procedure 

5.3.3  Check  routine  procedure 

5. 3- 3.1  Use  of  the  check  routine  procedure 

The  check  routine  procedure  may  be  used  in  the  following  cases  : 

a)  in  connection  with  an  Identity  request,  as  described  in  section  5.3.2; 

b)  for  updating  of  TEI  status  data,  as  an  audit  procedure. 

S.3.3.2  Operation  of  the  check  procedure 

The  check  routine  procedure  is  illustrated  in  Figure  5-2/Q.920. 


User  side 

UI  (SAPI,  TEI)  [ID  check  request,  Ai) 


ASP 


[ID  check  response,  Ai,  Ri)  (SAPI,  TEI)  UI 


-X 


SAPI  =  33 
TEI  =  127 


Start  T201 


FIGURE  5-2/Q. 920 
Check  routine 
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The  ASP  shell  transmit  e  message  containing  the  following  elements: 

a)  Message  type  “  Identity  check  request 

b)  the  TEI  value  to  be  checked  in  the  Ai  field 

Timer  T201  shall  be  started. 

If  any  user  equipment  has  been  assigned  the  TEI  value  specified  in  the  check 
message,  it  shall  respond  by  transmitting  a  message  containing  the  following  elements  : 

a)  Message  type  =  Identity  check  response 

b)  the  TEI  value  in  the  Ai  field 

c)  Reference  number  Ri 

The  Identity  check  response  informs  the  ASP  that  the  specific  TEI  value 
is  already  assigned. 

If  no  Identity  check  response  is  received  within  T201  the  request  shall  be 
repeated  once  and  T201  restarted.  (T201  is  defined  in  section  5.10-5*) 

If  no  response  is  received  afcer  the  second  Identity  check  request,  the 
TEI  value  shall  be  assumed  to  be  free  and  assigned  to  the  requesting  user. 

5.3-4  TEI  removal  procedure 

When  the  network  management  entity  determines  that  the  removal  of  a 
TEI  is  necessary  (for  example,  on  the  receipt  of  multiple  Identity  check  responses 
with  identical  values  of  Ai.but  differing  values  of  Ri.or  for  other  reasons),  the  ASP 
shall  transmit  a  message  containing  the  following  elements  : 

a)  Message  type  =  Identity  remove; 

b)  TEI  value  which  is  to  be  removed  in  the  Ai  field;  (the  value  127 
indicates  that  all  user  side  equipment  should  remove  their  TEI; 
otherwise,  the  specific  TEI  should  be  removed). 

Optionally,  the  ASP  may  invoke  the  check  routine  procedures  to  verify  that 
the  duplication  no  longer  exists. 


All  user  management  entities  receiving  the  Identity  remove  message 
containing  the  currently  assigned  TEI  value  in  the  Ai  field  shall  instruct  the 
data  link  layer  entity,  using  MDL-REMOVE-REQUEST ,  to  discard  the  TEI  value. 

5. 3. 4.1  Action  taken  by  the  data  link  layer  entity  receiving  MDL-REMOVE-REQUEST 

A  data  link  layer  entity  receiving  MDL-RH40VE-REQ0EST  shall  : 

a)  inform  layer  3  using  the  primitive  DL-RELEASE- INDICATION; 

b)  enter  the  TEI  unassigned  state. 
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5-3-5  Formats  and  codes 


5-3. 5.1  General 


All  messages  used  for  TEI  assignment  procedure  are  carried  in  the 
information  field  of  01  command  frames  with  a  SAPI  value  set  to  63  (binary  111  111) 
and  TEI  value  set  to  127  (binary  1111  111). 

All  messages  are  of  fixed  length  And  have  the  following  structure  : 


8  7  6  5.4,3. 

2  . 

1 

-  1  'T - ■ - - - -  r 

Management  entity  identifier 

— —  Reference  number 

— 

Message  type 

Action  indicator 

1 

Octet  1 

2 

3 

4 

5 


Fields  that  are  not  used  in  a  specific  message  are  coded  all  zeroes. 

The  coding  of  each  field  for  the  various  messages  is  specified  in 
Table  5-2/Q. 920. 

5.3- 5.2  Management  entity  identifier 

Octet  1  contains  the  management  entity  identifier*  Its  use  is  for 
further  study. 

5-3.5. 3  Reference  number  (Ri) 

Octets  2  and  3  contain  the  reference  number  (Ri) .  It  is  binary  coded 
and,  when  used,  can  assume  any  value  between  0  and  16383. 

5. 3*5. 4  Message  type 


Octet  4  contains  the  message  type.  The  purpose  of  the  message  type  is 
to  identify  the  function  of  the  message  being  sent. 
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5. 3.5. 5  Action  indicator  (Al) 

Octet  5  is  coded  as  follows  : 

a)  bit  1  is  always  coded  binary  1; 

b)  bits  2  to  8  contain  the  action  indicator. 
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The  purpose  of  the  action  indicator  is  to  identify  the  concerned  TEI  values. 

5-4  Automatic  negotiation  of  data  link  parameter  values 

The  automatic  negotiation  of  data  link  layer  parameter  values  is  for 
further  study. 

5.5  Procedures  for  single  frame  operation 

5.5.1  General 

The  following  procedures  shall  be  used  to  transfer  layer  3  information 
using  point-to-point  data  link  connections  when  in  the  link  connected  state.  The 
procedure  makes  use  of  TEN  frames. 

Note  -  When  using  these  procedures,  duplication  of  information  transfer  could  occur 
when  delays  in  the  order  of  timer  T200  are  encountered.  Further,  loss  of  information 
transfer  could  happen  if  the  state  variables  are  un synchronized  when  line  errors  occur. 
In  these  cases  no  notification  to  the  layer  3  would  be  made.  The  use  of  these 
procedures  should  suit  their  intended  application. 

A  data  link  layer  entity  which  only  implements  single  frame  operation  shall  : 

a)  on  receipt  of  DL-ESTABLISH-REQUEST ,  return  a  DL-ESTABLI SH-INDI CATI ON  and 
enter  the  single  frame  established  state; 
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b)  on  receipt  of  DL-RELEASE-REQUEST,  return  n  DL-RELEASE- INDI CATI ON 
and  enter  the  TEI  assigned  state. 

If  a  PH-DEACTIVATE-INDICATION  is  received  by  the  data  link  service  entity 
from  the  physical  layer  at  any  time  during  these  procedures,  the  data  link  layer 
entity  shall  inform  layer  3  by  using  the  primitive  DL-RELEASE-INDICATION. 

.2  Transmitting  TEN  command  frames 


Layer  3  will  pass  information  for  transmission  to  the  data  link  layer 
entity  by  means  of  the  primitive  DL-DATA-REQOEST. 

The  data  link  layer  entity  shall  : 

a)  set  the  poll  bit  N(P)  to  the  current  value  of  the  send  state  variable 
V(P)» 

b)  pass  the  frame  to  the  physical  layer  using  the  primitive  PH-DATA^ 
indicating  the  priority  parameter  of  the  SAPI; 

c)  start  timer  T200. 

Receiving  a  TBN  command  frame 


When  a  data  link  layer  entity  receives  a  TBN  command  frame  with  the  poll 
bit  N(P)  equal  to  the  current  value  of  its  final  bit  state  variable  V(F),  it  shall  : 

a)  pass  the  contents  of  the  information  field  to  layer  3  by  means  of 
the  primitive  DL-DATA-INDICATION-, 

b)  transmit  a  TBN  response  with  the  final  bit  N(F)  set  to  the  current 
value  of  the  state  variable  V(F) ; 

c)  complement  the  value  of  V(F). 

When  a  data  link  layer  entity  receives  a  TBN  command  frame  with  the  poll 
bit  not  equal  to  the  current  value  of  V(F),  the  frame  shall  be  discarded  and  a  TBN 
response  shall  be  transmitted  with  the  final  bit  N(F)  set  to  the  current  value  of 
the  state  variable  V(F).  V(F)  shall  not  be  completed. 

A  data  link  layer  entity  receiving  a  TBN  command  in  the  TEI  assigned  state 
shall  proceed  to  the  single  frame  established  state  and  shall  inform  layer  3  by 
using  the  DL-ESTABLISH-INDICATION  before  forwarding  the  data  in  the 
DL-DATA-INDICATION. 

Upon  receipt  of  a  TBN  command  frame  without  an  I  field,  the  procedures 
in  this  section  shall  be  followed  but  the  DL-DATA-INDICATION  shall  not  be  passed 
to  layer  3  entity. 


A  data  link  layer  entity,  on  receipt  of  a  TBN  response  frame  with  the 
final  bit  set  to  the  current  value  of  the  poll  bit  state  variable  V(P),  shall  : 

a)  complement  the  value  of  V(P); 
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b)  reset  timer  T200; 

c)  set  the  retransmission  count  variable  to  0. 

If  the  final  bit  N(F)  is  not  equal  to  the  current  value  of  V(P)  and  there 
have  been  no  retransmissions  of  the  TBN  command,  the  data  link  layer  entity  shall  : 

a)  complement  the  value  of  V(P); 

b)  retransmit  the  TBN  command  frame  with  the  poll  bit  set  to  the  current 
value  of  V(P); 

c)  restart  timer  T200; 

d)  increment  the  retransmission  count  variable. 

If  the  final  bit  N(F)  is  not  equal  to  the  current  value  of  V(P)  and  there 
have  been  re- transmissions  of  the  TBN  command,  the  data  link  layer  entity  shall  : 

-  assume  correct  delivery  of  the  TBN  command  frame; 

-  complement  the  value  of  V(P); 


-  reset  timer  T200; 


-  set  the  retransmission  count  variable  to  0. 
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5.5.5 


Waiting  acknowledgement 


The  data  link  layer  entity  shall  maintain  a  retransmission  count  variable 
which  is  set  to  0  when  a  new  TBN  command  is  transmitted.  The  counter  shall  be 
incremented  for  each  retransmission  of  the  frame;  i.e.  upon  the  expiry  of  T200. 

When  the  retransmission  count  variable  reaches  N200  (see  section  5.10.2)  the  data  link 
layer  entity  shall  inform  the  management  entity  by  means  of  MDL-ERROR  INDICATION, 
and  inform  layer  3  using  the  primitive  DL-RELEASE-INDICATION. 
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Procedures  for  establishment  and  release  of  multide  frame  operation 


Establishment  of  multiple  frame  operation 


5. 6. 1.1  General 

These  procedures  shall  be  used  to  establish  multiple  frame  operation  between 
the  network  and  a  designated  user  entity. 

The  layer  3  will  indicate  a  request  for  establishment  of  the  multiple  frame 
operation  by  the  use  of  the  DL-ESTABLISH-REQUEST  primitive.  Re-establishment  may  be 
initiated  as  a  result  of  the  data  link  layer  procedures  defined  in  section  5.8. 

All  frame  formats  other  than  U  frame  formats  received  during  the  establishment 
procedures  shall  be  ignored.  The  treatment  of  TBN  frames  received  during  the  establish 
ment  of  multiple  frame  operation  is  for  further  study. 

.6.1.2  Establishment  procedures 

A  data  link  layer  entity  shall  indicate  a  request  for  the  multiple  frame 
operation  to  be  set  by  transmitting  the  Set  Aysnchronous  Balanced  Mode  (SABM)  or  Set 
Asynchronous  Balanced  Mode  Extended  (SABME)  command.  Timer  T200  shall  then  be  started 
(timer  T200  is  defined  in  section  5.10.1).  All  mode  setting  commands  shall  be  trans¬ 
mitted  with  the  P  bit  set  to  1. 

A  data  link  layer  entity  receiving  an  SABM/ SABME  command  shall  : 

-  respond  with  an  Unnumbered  Acknowledgement  (UA)  response  with  the  F  bit  set 
to  the  same  binary  value  as  the  P  "bit  in  the  received  SABM/ SABME  command; 

-  set  the  send  state  variable  V(S),  receive  state  variable  V(R)  and  acknowledge 
state  variable  V(A)  to  0; 

-  enter  the  multiple  frame  established  state  and  inform  the  layer  3  using  the 
primitive  DL-ESTABLISH-INDI CATION; 

-  reset  the  retransmission  counter. 

If  the  data  link  layer  entity  is  unable  to  enter  the  multiple  frame 
established  state,  it  shall  respond  to  the  SABlV SABME  command  with  a  CM  response  with 
the  F  bit  set  to  the  same  binary  value  as  the  P  bit  in  the  received  SABM/ SABME  command. 

Upon  reception  of  the  UA  response,  the  originator  of  the  SABM/ SABME  shall  : 

-  stop  timer  T200; 

-  set  the  send  state  variable  V(S),  receive  state  variable  V(R)  and  acknowledge 
state  variable  V(A)  to  0; 

-  enter  the  multiple  frame  established  state  and  inform  the  layer  3  using  the 
primitive  DL-ESTABLISH-INDICATION; 

-  reset  the  retransmission  counter. 


Upon  reception  of  a  EM  response  with  F  bit  set  to  "1"  the  originator  of  the 
SABM/SABME  shall  indicate  this  by  means  of  the  primitive  DL- RELEASE- INDICATION  and 
MDL-ERROR-INDICATION  and  stop  timer  T200. 

5. 6. 1.3  Procedure  on  expiry  of  timer  T200 

If  timer  T200  expires  before  the  UA  or  DM  response  is  received  from  the 
network,  the  user  shall  : 

-  retransmit  the  SABM/SABME  command  as  above; 

-  restart  timer  T200; 

-  increment  the  retransmission  counter. 

After  retransmission  of  the  SABM/SABME  command  N200  times  the  data  link  layer 
entity  shall  indicate  this  by  means  of  the  primitive  DL- RELEASE-INDICATION  and  MDL- 
ERROR-INDICATION  and  enter  the  TEI  assigned  state. 

The  value  of  N200  is  defined  in  section  5.10.2. 

5-6.2  Information  transfer 

Having  either,  transmitted  the  UA  response  to  a  received  SABl^SABME  command, 
or  received  the  UA  response  to  a  transmitted  SABM/SABME  command,  I  and  S  frames  shall 
be  transmitted  and  received  according  to  the  procedures  described  in  section  5.7. 

If  an  SAB^/SABME  command  is  received  while  in  the  multiple  frame  established 
state  the  data  link  layer  entity  shall  conform  to  the  re-establishment  procedure 
described  in  section  5.8. 

On  receipt  of  a  UI  command  the  procedures  defined  in  section  5.2  shall  be 

followed. 

5.6.3  Termination  of  multiple  frame  operation 
5. 6. 3.1  General 


These  procedures  shall  be  used  to  terminate  the  multiple  frame  operation 
between  the  network  and  a  designated  user  entity. 

A  layer  3  entity  shall  indicate  a  request  for  termination  of  the  multiple 
frame  operation  by  use  of  the  DL-RELEASE-REQUEST  primitive. 

All  frame  formats  other  than  U  frame  formats  received  during  the  release 
procedures  shall  be  ignored. 

5. 6. 3. 2  Release  procedure 

A  data  link  layer  entity  shall  indicate  a  request  for  release  to  be  initiated 
by  transmitting  the  Disconnect  (DISC)  command  with  P  bit  set  to  1.  Timer  T200  shall 
then  be  started  and  the  retransmission  counter  reset. 
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A  data  link  layer  entity  receiving  a  DISC  command  while  in  the  multiple  frame 
established  state  shall  transmit  a  UA  response  with  the  F  bit  set  to  the  same  binary 
value  as  the  P  bit  in  received  DISC  command.  A  DL-RELEASE-INDI CATION  shall  be  passed 
to  the  layer  3. 

On  reception  of  the  UA  response  (or  DM  response  while  in  the  TEI  assigned 
state)  by  the  originator  of  the  DISC  command,  timer  T200  shall  be  stopped. 

The  data  link  layer  entity  will  now  be  in  the  TEI  assigned  state.  The 
conditions  relating  to  this  state  are  defined  in  section  5.6.4. 

5. 6. J. 3  Procedure  on  expiry  of  timer  T200 

If  timer  T200  expires  before  a  response  is  received,  the  originator  of  the 
DISC  command  shall  : 

-  retransmit  the  DISC  command  as  defined  in  section  5. 6. 3.2; 

-  restart  timer  T2Q0; 

-  increment  the  retransmission  counter. 

If  the  data  link  layer  entity  has  not  received  the  correct  response  as 
defined  in  section  5. 6. 3. 2,  after  N200  retransmissions  of  the  DISC  command,  the  data 
link  layer  entity  shall  indicate  this  by  means  of  the  primitive  DL-RELEASE- IN DI CAT I ON 
and  MDL-ERROR-INDI CATION  and  enter  the  TEI  assigned  state. 


5.6.4 


The  value  of  N200  is  defined  in  section  5.10.2. 

TEI  assigned  state 

While  in  the  TEI  assigned  state  : 

-  the  receipt  of  a  DISC  command  shall  result  in  the  transmission  of  a  IE 
response ; 

-  the  receipt  of  an  I  or  S  frame  with  the  P  bit  set  to  1  shall  result  in  the 
transmission  of  a  IE  response  with  the  F  bit  set  to  1  (as  defined  in 
section  5.1.1) • 


-  the  contents  of  any  received  I  frame  shall  be  discarded; 


iUB 


-  on  receipt  of  an  SABM/SABME  command,  the  procedures  defined  in  section  5.6.1 
shall  be  followed; 

-  on  receipt  of  UI  and  TBN  commands  and  responses,  the  procedures  defined  in 
sections  5.2  and  5.5  shall  be  followed; 


-  all  other  frame  types  shall  be  discarded. 


m 


Note  -  If  the  user  side  link  layer  entity  does  not  support  single  frame  operation,  any 
received  TBN  frames  may  be  discarded. 
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5.6.5  Collision  of  unnumbered  commands 

Collision  situations  shall  be  resolved  in  the  following  wa y  : 

5.6. 5.1  Identical  transmitted  and  received  commAnds 

If  the  transmitted  and  received  U  commands  (SABM  or  SAB ME  or  DISC)  are  the 
same,  the  data  link  layer  entities  shall  send  the  UA  response  at  the  earliest  possible 
opportunity.  The  indicated  state  shall  be  entered  after  receiving  the  HA  response. 

The  data  link  layer  entities  shall  notify  their  respective  layer  3  entities,  by  means 
of  the  appropriate  indication  primitive. 

5.6. 5.2  Different  transmitted  and  received  commands 

If  the  transmitted  and  received  U  commands  (SABM  or  SABME  or  DISC)  are 
different,  the  data  link  layer  entities  shall  enter  the  TEI  assigned  state  and  issue  a 
DM  response  at  the  earliest  possible  opportunity.  The  data  link  layer  entitles 
shall  notify  their  respective  layer  3  entities  by  means  of  the  DL- RELEASE-INDICATION 
primitive. 

5.6. 5.3  Unsolicited  DM  response  and  SABM  or  DISC  command  may  be  received  when  a 

DM  response  is  issued  by  a  data  link  layer  entity  at  the  user  side,  this  is  typically 
a  terminal  applying  a  protocol  procedure  according  to  X.25,  to  ask  for  a  mode-setting 
command,  a  collision  between  an  SABM  or  DISC  command  and  the  unsolicited  DM  response 
may  occur. 


In  order  to  avoid  misinterpretation  of  the  DM  response  received,  a  data  link 
layer  entity  shall  always  send  its  SABM  or  DISC  command  with  the  P  bit  set  to  1. 

The  recovery  from  this  collision  situation  is  for  further  study. 

5.7  Procedures  for  multiple  frame  operation 

The  procedures  which  apply  to  the  transmission  of  I  frames  are  defined  below. 

5-7.1  Transmitting  I  frames 

Information  received  by  the  data  link  layer  entity  by  means  of  a  DL-DATA- 
REQUEST  primitive  shall  be  transmitted  in  an  I  frame.  The  control  field  parameters  N(S) 
and  N(R)  shall  be  assigned  the  values  of  the  send  and  receive  state  variables  V(S)  and 
V(R)  respectively.  The  value  of  the  send  state  variable  V(S)  shall  be  incremented 
by  1. 


If  timer  T200  is  not  running  at  the  instant  of  transmission  of  an  I  frame,  it 
shall  be  started.  If  timer  T200  expires,  the  procedures  defined  in  section  5.7.7 
shall  be  followed. 

If  the  send  state  variable  V(S)  is  equal  to  V(A)  plus  k  (where  k  is  the 
maximum  number  of  outstanding  I  frames  -  see  section  5.10.4),  the  data  link  layer 
entity  shall  not  transmit  any  new  I  frames,  but  may  retransmit  an  I  frame  as  a  result 
of  the  error  recovery  procedures. 
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When  the  network  side  or  user  aide  is  in  the  receiver  busy  condition,  it 
say  still  transmit  I  frames,  provided  that  its  peer  is  not  busy  itself.  When  the 
network  aide  or  user  side  is  in  the  frame  rejection  condition,  it  shall  stop  transmit¬ 
ting  I  frames. 


5.7.2 


iceiving  I  frames 


When  a  data  link  layer  entity  ia  not  in  a  receiver  busy  condition  and 
receives  an  I  frame  whose  send  sequence  number  is  equal  to  the  current  receive  state 
variable  V(R),  the  data  link  layer  entity  shall  : 

-  pass  the  information  field  of  this  frame  to  the  layer  3  using  the 
primitive  DL- DATA-INDIC ATION ; 

-  increment  by  1  its  receive  state  variable  V(R),  and  act  as  follows  : 

5. 7. 2.1  If  the  P  bit  of  the  received  I  frame  was  set  to  binary  nln,  the  data  link 

layer  entity  shall  transmit  an  RR  response  with  the  F  bit  set  to  binary  "1"  (as 
defined  in  section  5.1.1). 

5. 7. 2. 2  If  the  P  bit  of  the  received  I  frame  was  set  to  binary  nOn  and  ; 

-  if  no  I  frame  is  available  for  transmission  or  if  an  I  frame  is  available 

for  transmission  but  the  peer  entity  has  indicated  a  receiver  busy  condition, 
the  data  link  layer  entity  shall  transmit  an  RR  response  with  the  F  bit  set 
to  binary  "0"j 

-  if  an  I  frame  is  available  for  transmission,  the  data  link  layer  entity 
shall  in  all  cases  (except  when  the  peer  entity  is  busy)  transmit  the  I  frame 
with  the  value  of  N(R)  set  to  the  current  value  of  V(R)  as  defined  in 
section  5.7.1. 


When  the  data  link  layer  entity  is  in  a  receiver  busy  condition,  it  shall 
process  any  received  I  frame  according  to  section  5.7.6. 

5-7.3  Receiving  acknowledgement 

On  receipt  of  a  valid  I  or  S  frame  (RR,  RNR  or  REJ),  even  in  the  busy  timer 
recovery  or  frame  rejection  condition,  the  data  link  layer  entity  shall  treat  the  N(R) 
contained  in  this  frame  as  an  acknowledgement  for  all  the  I  frames  it  has  transmitted 
with  an  N(S)  up  to  and  including  the  received  N(R)-1.  The  value  of  the  acknowledge 
state  valrable  V(A)  shall  be  set  to  the  value  of  N(R).  The  i?ta  link  layer  entity 
shall  reset  the  timer  T200  on  receipt  of  a  valid  I  or  S  frame  with  the  N(R)  higher 
than  7(A)  (actually  acknowledging  some  T  frames). 

If  timer  T200  has  been  reset,  and  if  there  are  outstanding  I  frames  still  un¬ 
acknowledged,  the  data  link  layer  entity  shall  restart  timer  T200.  If  timer  T200  then 
expires,  the  data  link  layer  entity  shall  follow  the  retransmission  procedure  as 
defined  in  section  5.7.7  with  respect  to  the  unacknowledged  I  frames. 


V  ' 


In  the  following  text  in  this  Recommendation,  the  term  receiver  busy  refers  to  the 
peer-to-peer  flow  control  state  in  the  data  link  layer. 
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5.7.4 


Receiving  reject 


On  receipt  of  an  REJ  frame,  the  data  link  layer  entity  shall  set  its  send 
state  variable  V(S)  to  the  value  of  the  N(R)  contained  in  the  REJ  frame  control  field. 

It  shall  reset  timer  T200  and  clear  the  timer  recovery  condition.  It  shall  transmit 
the  corresponding  I  frame  as  soon  as  possible  as  defined  in  section  5.7.1.  .  Transmission 
shall  take  account  of  the  following  : 

1)  if  the  data  link  layer  entity  is  transmitting  a  frame  when  it  receives 

the  REJ,  it  shall  complete  that  transmission  before  commencing  transmission 
of  the  requested  I  frame. 

2)  if  the  data  link  layer  entity  is  not  transmitting  a  frame  when  the  REJ  is 
received,  it  shall  immediately  commence  transmission  of  the  request  I  frame. 

All  outstanding  unacknowledged  I  frames,  commencing  with  the  I  frame 
identified  in  the  received  REJ  command  shall  be  transmitted. 


5.7.5 


Receiving 


After  receiving  an  RNR  command  or  response,  if  the  data  link  layer  entity 
is  not  engaged  in  a  mode  setting  operation  it  shall  set  its  acknowledge  state 
variable  V(A)  to  the  value  of  N(R)  contained  in  the  control  field.  The  following  shall 
then  be  performed  : 

-  the  data  link  layer  entity  shall  transmit  a  supervisory  command  (RR,  RNR 
or  REJ)  in  order  to  determine  if  there  is  any  change  in  the  status  of  the 
peer  entity.  The  P  bit  shall  be  set  to  binary  1} 

-  timer  T200  shall  be  started. 

The  data  link  layer  entity  receiving  the  supervisory  frame  with  P  bit  set 
to  1  shall  respond  with  a  supervisory  response  frame  (RR,  RNR,  REJ)  with  an  F  bit  set 
to  binary  1,  to  indicate  whether  or  not  the  busy  condition  still  exists. 

Upon  receipt  of  the  supervisory  response,  the  data  link  layer  entity  shall 
reset  timer  T200  and  : 

-  if  the  response  is  RR  or  REJ,  the  data  link  layer  entity  may  transmit  new 
I  frames  or  retransmit  I  frames  as  defined  in  section  5.7.1; 

-  if  the  response  is  RNR,  the  data  link  layer  entity  receiving  the  response 
shall  repeat,  possibly  after  some  delay  which  is  implementation  dependent, 
the  enquiry  of  the  peer  status. 

Note  1  -  The  N(R)  in  the  received  supervisory  response  with  F  bit  set  to  1  may  be  used 
to  update  the  send  state  vairable  V(S). 

Note  2  -  Further  study  is  needed  on  whether  the  N(R)  in  a  received  supervisory  RNR 
command  with  a  P  bit  set  to  1  may  be  used  to  update  the  send  state  variable  V(S). 

Note  3  -  In  order,  to  optimize  the  procedures ,  I  frames  should  not  be  transmitted  towards 
a  peer  which  has  indicated  a  busy  condition  with  RNR. 
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If  the  timer  T200  runs  out  before  a  status  response/command  is  received,  the 
enquiry  process  above  is  repeated  with  the  exception  that  the  re-transmission  count 
variable  is  incremented  rather  than  being  reset.  If  N200  attempts  to  get  a  status 
response  fail  (e.g.  timer  T200  runs  out  N200  times),  the  data  link  layer  entity  will 
initiate  the  re-establishment  procedure  described  in  section  5-8.  The  management  entity 
shall  be  notified  via  the  MDL-ERROR- INDICATION  primitive.  (N200  is  a  system  parameter, 
see  5.10.2). 

If  a  supervisory  command  (RR,  RNR  or  REJ )  is  received  during  the  inquiry 
process,  the  data  link  layer  entity  shall  reset  timer  T200  and; 

-  if  the  command  is  the  RR  or  REJ  command,  the  busy  condition  is  cleared  and 
the  data  link  layer  entity  may  transmit  new  I  frames  or  re- transmit  I  frames 
as  specified  in  sections  5.7.1  or  5*7.4; 

-  if  the  command  is  an  RNR  command,  the  busy  condition  still  exists.  The  data 
link  layer  entity  will  stop  timer  T200  and  reply  with  an  appropriate  response 
frame.  The  inquiry  of  the  peer  status  shall  be  repeated  possibly  after  some 
delay  which  is  implemented  dependent. 

Should  the  received  S  command  contain  the  Poll  bit  set  to  "1",  the  appropriate 
response  frame  with  the  Final  bit  set  to  nl"  must  be  transmitted  before  the  data  link 
layer  entity  can  action  the  received  frame. 

5-7.6  Data  link  layer  receiver  busy  condition 

When  the  data  link  layer  entity  enters  a  receiver  busy  condition  it  shall 
transmit  an  RNR  response  at  the  earliest  opportunity.  An  RNR  command  may  be  transmitted 
instead  of  RNR  response  to  indicate  the  busy  condition  and  simultaneously  poll  the 
status  of  peer  entity. 

All  received  I  frames  with  the  Poll  bit  set  to  binary  "0"  may  be  discarded, 
after  updating  the  receive  state  variable  V(R)  and  acknowledge  state  variable  V(A). 

All  received  I  frames  with  the  Poll  bit  set  to  binary  "1"  may  be  descarded, 
after  updating  the  acknowledge  state  variable  V(A).  However,  an  RNR  response  frame 
with  the  Final  bit  set  to  binary  "1"  shall  be  transmitted. 

To  indicate  a  clearance  of  the  receiver  busy  condition,  the  data  link  layer 
entity  shall  transmit  an  RR  or  REJ  frame  with  N(R)  set  to  the  current  receive  state 
variable  V(R). 

The  busy  condition  may  also  be  cleared  by  the  transmission  of  an  SABH/SABME 

command . 

5.7.7  Waiting  acknowledgement 

The  data  link  layer  entity  shall  maintain  an  internal  retransmission  count 
variable  which  is  set  to  0  when  the  data  link  layer  entity  transmits  or  receives  a  UA 
response,  an  RNR  response,  .or  when  the  data  link  layer  entity  receives  a  valid  I  or 
S  frame  with  the  N(R)  higher  than  the  last  received  N(R)  (that  is,  acknowledging 
outstanding  I  frames). 
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If  tiaer  T200  expires  the  data  link  layer  entity  shall 

-  enter  the  tiaer  recovery  condition; 

-  add  one  to  its  retransaission  count  variable; 


-  set  an  internal  variable  "X"  to  the  current  value  of  its  send  state  variable 
V(S). 


The  data  link  layer  entity  shall  then 
-  restart  tiaer  T200; 


-  set  its  send  state  variable  V(S)  to  V(A),  and  retransait  the  corresponding 
I  frame  with  the  P  bit  set  to  binary  ”1";  or 


-  transmit  an  appropriate  supervisory  command  with  the  P  bit  i,et  to  binary  nln; 
or 


-  retransmit  the  last  transmitted  I  frame  (V(S)-l)  with  the  P  bit  set  to 
binary  "1". 


The  timer  recovery  condition  is  cleared  when  the  data  link  layer  entity 
receives  a  valid  S  frame  response  with  the  F  bit  set  to  binary  "1"  and  may  be  cleared 
by  receiving  an  I  or  S  frame  acknowledging  all  outstanding  I  frames. 


If  the  received  frame  N(R)  is  within  the  range  from  its  current  send  state 
variable  V(S)  to  "X"  inclusive,  it  shall  set  its  send  state  variable  V(S)  to  the  value 
of  the  received  N(R). 


If,  while  in  the  timer  recovery  condition,  the  data  link  layer  entity 
receives  a  valid  supervisory  frame  with  the  F  bit  set  to  binary  "0"  and  with  an  N(R) 
within  the  range  from  its  current  send  state  variable  V(S)  to  "X"  exclusive,  it  shall 
not  clear  the  tiaer  recovery  condition.  The  value  of  the  received  N(R)  shall  be  used 
to  update  the  send  state  variable  V(S}  and  acknowledge  state  variable  V(A). 


If  the  retransaission  count  variable  is  equal  to  N2,  the  data  link  layer 
entity  shall  initiate  a  re-establishment  procedure  as  defined  in  section  5-8  and 
indicate  this  by  means  of  the  primitive  MDL-ERROR-INDICATION  to  the  management  entity. 
(N200  is  a  system  parameter,  see  section  5.10.2.) 


5-8  Re-establishment  of  Multiple  frame  operation 

5-8.1  Criteria  for  re-establishment 


The  procedures  for  re-establishing  the  multiple  frame  operation  are  defined 
in  this  section  and  are  initiated  by  the  receipt  of  the  DL-ESTABLISH-REQUEST  from 
the  layer  3  in  the  normal  state  or  by  the  following  conditions  : 


-  the  receipt  of  frame  with  procedure  errors  as  defined  in  section  5.9.4; 


-  the  receipt,  while  in  the  multiple  frame  established  state  of  an  unsolicited 
DM  response  or  FKMR  response; 
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-  the  receipt,  while  in  the  multiple  frame  established  state  of  a  DA  response 
or  other  unsolicited  response  with  the  F  bit  set  to  binary  "1"; 

-  N200  retransmission  failures  while  in  the  multiple  frame  established  state. 
5.8*2  Procedures 

5. 8. 2.1  Under  normal  conditions,  the  procedures  defined  in  section  5.6.1  shall  be 
used  to  re-establish  multiple  frame  operation. 

5. 8. 2. 2  Under  certain  conditions  listed  in  section  5*8.1,  either  side  may  request 
re-establishment  of  the  link  by  transmitting  an  FRMR  response.  The  data  link  layer 
entity  detecting  a  receive  sequence  number  error  may  re-establish  the  multiple  frame 
operation  ty  immediate  transmission  of  a  SABM/SABME  command. 

After  transmitting  an  FRMR  response  the  data  link  layer  entity  shall  enter 
the  frame  rejection  condition  :  the  frame  rejection  condition  is  cleared  when  the 
data  link  layer  entity  receives  an  SABM/SABME  or  DISC  command. 

Any  other  command  received  while  in  the  frame  rejection  condition  shall 
cause  the  data  link  layer  entity  to  retransmit  the  FRMR  response  with  the  same 
information  field  as  originally  transmitted. 

After  receiving  FRMR  the  data  link  layer  entity  shall  initiate  the  re¬ 
establishment  procedures  as  defined  in  section  5.6.1  and  indicate  this  by  means  of 
the  primitive  MDL-ERROR-INDICATION  to  the  management  entity. 

5.9  Exception  condition  reportin£  the  recovery 


Exception  conditions  may  occur  as  the  result  of  physical  layer  errors  or 
data  link  layer  procedural  errors. 

The  error  recovery  procedures  which  are  available  to  effect  recovery 
following  the  detection  of  an  exception  condition  at  the  data  link  layer  are  defined 
in  this  section. 

5.9.1  NfS)  sequence  error 

'n  N(S)  sequence  exception  condition  occurs  in  the  receiver  when  a  valid 
I  frame  is  received  which  contains  an  N(S)  value  which  is  not  equal  to  the  receive 
state  variable  V(R)  at  the  receiver.  The  information  field  of  all  I  frames  whose  N(S) 
does  not  equal  the  receive  state  variable  V(R)  shall  be  discarded. 


*  »  • 


The  receiver  shall  not  acknowledge  (nor  increment  its  receive  state  variable) 
the  I  frame  causing  the  sequence  error,  nor  any  I  frames  which  may  follow,  until  an 
I  frame  with  the  correct  H(S)  is  received. 

A  data  link  layer  entity  which  receives  one  or  more  I  frames  having  sequence 
errors  but  otherwise  error-free  shall  use  the  control  field  information  contained 
in  N(R)  and  the  P  bit  to  perform  link  control  functions;  for  example,  to  receive 
acknowledgement  of  previously  transmitted  I  frames  and  to  cause  the  data  link  layer 
entity  to  respond  if  the  P  bit  is  set  to  binary  "1".  Therefore,  the  retransmitted 
I  frame  may  contain  an  M(R)  field  and  P  bit  that  are  updated  from  and  therefore 
different  from,  the  ones  contained  in  the  originally  transmitted  I  frame. 
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The  REJ  is  used  to  initiate  an  exception  recovery  (retransmission)  following 
the  detection  of  an  N(S)  sequence  error. 


Only  one  REJ  exception  condition  from  a  data  link  layer  entity  shall  be 
active  at  a  time  on  one  data  link  correction. 


A  data  link  layer  entity  receiving  a  REJ  command  or  response  shall  initiate 
sequential  transmission  (retransmission)  of  I  frames  starting  with  the  I  frame 
indicated  by  the  N(R)  contained  in  the  REJ.  fbame. 


A  REJ  exception  condition  is  cleared  when  the  requested  I  frame  is  received 
or  when  an  SABM,  SABME  or  CISC  is  received. 


5-9.2  Time-out  recover 


If  a  data  link  layer  entity  due  to  an  error,  does  not  receive  a  single 
I  frame  or  the  last  I  frame  in  a  sequence  of  I  frames,  it  will  not  detect  an  out-of¬ 
sequence  exception  condition  and  therefore  will  not  transmit  REJ. 


The  data  link  layer  which  transmitted  the  unacknowledged  I  frame(s)  shall, 
on  the  expiry  of  timer  T200,  take  appropriate  recovery  action  as  defined  in 
section  5.7.7  to  determine  at  which  I  frame  retransmission  must  begin. 


5.9.3 


Invalid  frame 


Any  frame  received  with  an  FCS  error  or  which  is  invalid  (as  defined  in 
section  2.10)  shall  be  discarded. 


Note  -  Any  additional  action,  e.g.  error  rate  monitoring  to  be  taken  by  the  data  link 
layer  is  for  further  study. 


5.9.4 


Frame  rejection  condition 


A  frame  rejection  condition  shall  be  established  upon  the  receipt  of  : 


-  an  error  free  frame  which  is  unknown  as  a  command  or  response; 


-  an  invalid  frame  format; 


an  invalid  N(R); 


Note  -  Upon  the  receipt  of  an  invalid  N(R) ,  link  re-establishment  may  be 
performed  rather  than  establishing  a  frame  rejection  condition.  Further 
study  is  required  on  which  of  the  alternatives  is  the  preferred  method. 


-  an  information  field  which  exceeds  the  maximum  information  field  length 
which  can  be  accommodated. 


At  either  side,  this  frame  rejection  condition  shall  be  indicated  by 
transmission  of  an  FRMR  response  for  appropriate  action,  followed  by  the  transmission 
of  an  SABM,  SABME  or  DISC  command.  Rather  than  establishing  a  frame  rejection 
condition  link  re-establishment  may  be  initiated  directly  at  the  user  side  (see 
section  5.8.2). 
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Once  the  frame  rejection  condition  has  been  established,  no  additional 
I  frames  shall  be  processed  (except  for  examination  of  the  P  bit)  until  the  condition 
is  reset. 


The  FRMR  response  may  be  repeated  at  each  opportunity  until  recovery  is 

effected. 

5.10  List  of  system  parameters 


■".•4 


The  following  system  parameters  listed  below  are  associated  with  each 
individual  service  access  point. 

A  method  of  assigning  these  parameters  is  defined  in  section  5*4.  Other 
methods  of  assigning  these  parameters  may  be  available,  but  are  not  part  of  this 
Recommendation . 

5.10.1  Timer  T200 

The  default1  value  for  timer  T200  at  the  end  of  which  transmission  of  a 
frame  may  be  initiated  according  to  the  procedures  described  in  sections  5.5  and  5.6 
shall  be  one  second. 


IW.I 


Note  -  The  proper  operation  of  the  procedure  requires  that  timer  T200  be  greater  than 
the  maximum  time  between  transmission  of  command  frames  and  the  reception  of  their 
corresponding  response  or  acknowledgement  frames. 

5.10.2  Maximum  number  of  retransmissions'  (N20Q) 

The  maximum  number  of  retransmissions  of  a  frame  (N200)  is  a  system  parameter. 
The  default  value  of  N200  shall  be  3- 

5.10.3  Maximum  number  of  octets  in  an  I  field  (Nl) 

The  maximum  number  of  octets  in  an  I  field  (Nl)  is  a  system  parameter.  (See 
also  section  2.5). 


-  For  an  SAP  supporting  signalling,  the  default  value  shall  be  128  octets 
(provisional  value). 

Note  -  For  applications  requiring  large  signalling  messages,  a  single  value 
greater  than  128  (e.g.  260)  may  be  specified. 

-  For  SAPs  supporting  packet  information,  the  default  value  shall  be  260  octets 
(provisional  value ) . 

Note  -  If  and  when  other  SAP  types  are  defined,  the  appropriate  default  values  will  be 
included  in  the  Recommendation. 
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The  term  default  implies  that  the  value  defined  should  be  used  in  the  absence  of 
any  assignment  or  negotiation  of  alternative  values. 
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The  maximum  number  (k)  of  sequentially  numbered  I  frames  that  may  be 
outstanding  (i.e.  unacknowledged)  at  any  given  time  is  a  system  parameter  which  shall 
not  exceed  7. 

-  For  an  SAP  supporting  signalling,  the  default  value  shall  be  1, 

-  for  SAPs  supporting  packet  information,  the  default  value  shall  be  7. 

For  extended  mode  operation  (e.g.  satellite  links),  the  permissible  maximum 
number  of  outstanding  I  frames  may  be  increased  to  any  value  up  to  127. 

5.10.5  Timer  T201 

The  minimum  time  between  retransmission  of  the  TEI-identity  check  messages 
(T201)  is  a  system  parameter  which  shall  be  set  to  T200  seconds. 

5.10.6  Timer  T202 

The  minimum  time  between  the  transmission  of  TEI-identity  request  messages 
is  a  system  parameter (T202)  which  shall  be  set  to  3xT200  seconds. 
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APPENDIX 


1.  Introduction 

The  procedural  elements  defined  in  section  5  of  Q.920  allow  for  the 
supervision  of  the  data  link  layer  resource.  This  Appendix  describes  procedures  vhich 
may  be  used  to  provide  this  supervision  function.  Procedures  for  both  the  single 
frame  operation  and  the  multiple  frame  operation  are  described.  The  use  of  this 
function  is  optional. 

2.  Link  layer  supervision  in  the  multiple  frame  established  state 

The  procedures  specified  herein  propose  a  solution  which  is  already  identified 
in  the  HDLC  classes  of  procedures.  The  connection  verification  is  a  service  provide! 
by  data  link  layer  to  layer  3.  This  implies  that  layer  3  is  informed  in  case  of  a 
failure  only.  Furthermore,  the  procedure  may  be  incorporated  in  the  "normal"  exchange 
of  information  and  may  become  more  efficient  than  a  procedure  based  on  the  involvement 
of  layer  3. 


The  procedure  specified  herein  is  called  STATUS  ENQUIRY  and  is  based  on 
S  command  frames  (RR  command,  RNR  command)  and  a  timer  T203  and  operates  in  the  multiple 
frame  established  state  as  follows  : 

If  there  are  no  frames  being  exchanged  on  the  data  link  connection  (neither 
new  nor  outstanding  I  frames  or  no  S  frames  with  a  P  bit  set  to  I  etc.),  there  is  no 
means  to  detect  a  faulty  data  link  connection  condition  or  if  a  TE  has  been  unplugged. 
Timer  T203  represents  the  maximum  time  allowed  without  frames  being  exchanged. 

If  timer  T203  expires,  a  supervisory  command  with  a  P  bit  set  to  1  is 
transmitted  to  start  a  STATUS  ENQUIRY.  Such  a  status  enquiry  is  protected  against 
corruption,  making  use  of  the  normal  timer  T200  procedure  including  retransmission 
count  and  N200  attempts. 

2.1  Connection  verification  procedures 

2.1.1  Restart  of  timer  T203 
Upon  receiving  a  frame  timer  T203  will  be  restarted. 

2.1.2  Exnlry  of  timer  T203 

Timer  T203  supports  a  supervisory  mechanism  to  detect  a  faulty  data  link 
connection  condition  or  if  a  TE  has  been  unplugged  during  intervals  when  there  are  no 
outstanding  frames  in  either  direction.  It  represents  the  maximum  time  allowed 
without  frames  being  exchanged  on  a  data  link  layer  connection. 

If  timer  T203  expires,  the  data  link  layer  entity  will  act  as  follows  (it 
should  be  noted  that  timer  T200  is  neither  running  nor  expired)  : 

1)  set  the  retransmission  count  variable  to  0; 

2)  set  STATUS  ENQUIRY; 
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3)  transmit  a  supervisory  command  with  the  P  bit  set  to  1  as  follows  : 

-  if  there  is  not  a  receiver  busy  condition  (own  receiver  not  busy),  transmit 
an  RE  command; 

-  if  there  is  a  receiver  busy  condition  (own  receiver  busy),  transmit  an  RNR 
command - 

4)  start  timer  T200. 

Note  -  Timer  T203  may  not  be  needed  at  the  user  side. 

3.  Link  layer  supervision  in  the  single  frame  established  state 

Link  supervision  in  the  single  frame  established  state  may  be  performed  as 
f #llows .  A  data  link  layer  entity  which  detects  that  no  frames  have  been  exchanged 
ai  the  link  for  a  period  of  time  would  send  a  TBN  command  frame  with  a  zero  length 
Information  field.  The  entity  receiving  the  TBN  command  would  respond  with  a  TBN 
•espouse.  Both  transmission  and  reception  of  these  frames  should  conform  to  the 
procedures  defined  in  section  5.5.  The  DL-DATA-INDICATION  primitive  should  not  be 
passed  to  the  layer  3,  since  there  is  no  information  field  in  received  TBN  frames. 
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1.  General 

This  Recommendation  specifies  the  procedures  for  the  establishing, 
maintaining  and  clearing  of  network  connections  at  the  ISDN  user-network  interface. 
These  procedures  are  defined  in  terms  of  messages  exchanged  over  the  D-channel  of  basic 
and  primary  rate  interface  structures  and  the  E-channel  of  the  primary  rate  interface 
defined  in  Recommendation  I. 41?  /~1  7-  The  functions  and  procedures  of  this  protocol, 
and  the  relationship  with  other  layers,  are  described  in  general  terms  in 
Recommendation  Q .929  (1.450)  /  2  7*  la  this  Recommendation,  all  references  to  the 
D— channel  protocol  should  be  assumed  to  apply  to  the  E— channel  unless  otherwise 
specified. 

1.1  Scone  of  the  Recommendation 

The  procedures  currently  described  in  this  Recommendation  are  for  the  control 
of  circuit  switched  connections,  user-to-user  signalling  connections,  and  packet 
switched  connections.  The  carriage  of  other  message  based  information  flows  (telemetry 
etc.)  on  the  D-cbannel  is  a  subject  for  further  study  and  will  be  included  in  later 
versions  of  this  Recommendation. 

1.2  Structure  of  the  Recommendation 

The  remaining  sections  of  this  Recommendation  are  as  follows. 

Section  2  -  Overview  of  call  control 
Section  3  -  Message  functional  definitions 
Section  4  -  Message  structure 
Section  5  -  Call  control  procedures 

Section  6  -  Application  of  circuit-switched  call  control  procedures  to 
terminals  operating  in  a  stimulus  mode 


The  layer  3  grocedures  apply  to  the  interface  structures  defined  in 
Recommendation  1.412  /  1_7-  They  use  all  of  the  functions  and  services  provided  by 
layer  2  with  the  exception  of  the  unacknowledged  information  transfer  service  which  is 
used  only  on  basic  access  interface  structures  to  provide  point-to-multipoint  operation 
at  layer  3. 


In  this  Recommendation  the  terms  "incoming"  and  "outgoing"  are  used  to 
describe  the  call  as  viewed  by  the  user  side  of  the  interface. 


This  section  provides  the  definition  for  states  that  individual  calls  may 
have,  and  provides  overview  SDL  diagrams  for  the  user  and  network  side  of  the  interface. 
These  definitions  do  not  apply  to  the  state  of  the  interface  itself,  any  attached 
equipment,  the  D-channel,  or  the  logical  links  used  for  signalling  on  the  D-channel  and 
do  not  apply  to  the  state  of  the  call  reference.  They  are  call  states.  Because 
several  calls  may  exist  simultaneously  at  a  user-network  interface,  and  each  call  may  be 
In  a  different  state,  the  state  of  the  interface  itself  cannot  be  unamfciffuousl:/'  defined. 


The  overview  SDL  diagrams  (Figure  2/Q.930  and  Figure  3/Q.930)  are  provided  to 
give  an  overview  of  the  procedures  for  a  circuit  switched  call.  The  diagrams  do  not 
show  all  details  and  show  only  some  of  the  messages  possible  at  each  state,  generally 
those  messages  most  likely  to  occur  at  each  state.  Similarly,  to  provide  a  simple 
overview,  timers  and  their  operation  are  not  in  general  shown  explicitly.  Internal 
requests  from  the  network  and  user  sides  are  shown  where  necessary  for  comprehension, 
but  other  internal  messages  at  the  user  and  network  sides  are  not  shown.  The  call 
reference  may  vary  during  a  call  and  is  not  necessarily  held  for  the  duration  of  a 
call  (e.g.  call  suspension). 


Detailed  description  of  the  procedures  for  call  control  are  given  in  i  5.1 
in  terms  of  the  sequence  of  messages  defined  in  §  3  which  are  transferred  across  the 
user-network  interface,  and  the  information  processing  and  actions  that  take  place  in 
terminal  and  the  exchange  in  the  process  of  call  establishment  and  clearing. 
Transitions  between  the  states  defined  in  this  section  are  included  with  the  message 
definitions  in  §  3.  Detailed  SDL  diagrams  for  call  control  of  circuit- switched  calls 
are  contained  in  S  5. 


Throughout  this  Recommendation  reference  to  B-channels  is  made  as  far  as 
circuit-switched  calls  are  concerned.  The  application  of  the  call  control  procedures 
defined  in  this  Recommendation  to  other  channel  types  is  not  excluded.  Further  study 
on  extending  the  application  to  other  channels  types  is  needed. 


at  the  user  side  of  the  interface 


The  states  which  may  exist  on  the  user  side  of  the  user-network  interface  are 
defined  in  this  section. 


2.1.1. 1 


No  call  exists. 


2.1.1. 2 


This  state  exists  for  an  outgoing  call,  as  a  result  of  user  action  requesting 
call  establishment. 


2.1. 1.3 


This  state  exists  for  an  outgoing  call  while  the  user  is  sending  call  set-up 
information  to  the  network  in  the  overlap  mode. 


2. 1.1. 4 


This  state  exists  for  an  outgoing  call,  of  the  interface,  when  the  network 
has  acknowledged  receipt  of  complete  information  required  for  call  establishment,  and 
awaits  called  terminal  response. 


2.1. 1.5 


This  state  exists  for  an  outgoing  call,  when  the  network  has  completed 
processing  the  call  to  the  point  of  receiving  alerting  from  the  user-network  interface 
indicated  by  the  called  address,  or  an  alternate  interface  specified  either  by  the 
called  user  or  the  network  (e.g.  inband  tones  or  announcements ) . 


This  state  exists  for  an  incoming  call,  while  negotiation  for  a  suitable 
B-channel  is  in  progress. 

2. 1.1. 7  Call  received  (P7) 

This  state  exists  for  an  incoming  call  when  a  response/answer  is  awaited 
while  alerting  by  the  user. 

2.1. 1.8  Connect  request  (U8) 

This  state  exists  for  an  incoming  call  while  awaiting  receipt  from  the 
network  of  a  connect  acknowledgement. 

2.1. 1.9  Active  (U9) 

This  state  exists  when  a  call  is  in  the  end-to-end  communication  mode . 

2.1.1.10  Disconnect  request  (U10) 

This  state  exists  in  response  to  a  request  to  disconnect  a  call,  prior  to 
acknowledgement  by  the  network. 

2.1.1.11  Disconnect  indication  (Dll) 

This  state  exists  when  the  network  has  indicated  disconnect  and  the  user  has 
not  yet  indicated  release  or  detach. 

2.1.1.12  Detach  (D12) 

This  state  exists  when  the  B-channel  has  been  released  but  the  call  has  not 
been  cleared. 

2.1.1.13  Suspend  request  (U13) 

This  state  exists  in  response  to  user  action  to  initiate  terminal  move 
procedures  locally,  prior  to  acknowledgement  by  the  network. 

2.1.1.14  Local  suspend  (014) 

This  state  exists  in  response  to  a  suspend  request,  following  receipt  of  the 
acknowledgement  of  the  suspend  request  by  the  network. 

2.1.1.15  Resume  request  (U15) 


This  state  exists  in  response  to  a  request  to  resume  a  previously  suspended 
call,  prior  to  acknowledgement  by  the  network. 


This  state  exists  in  response  to  a  request  from  the  network  for  the 
activation  of  a  facility,  prior  to  user  response. 

2.1.1.17  local  facility  request  (U19l 

This  state  exists  after  a  request  by  the  user  to  the  network  for  the 
activation  of  a  facility,  prior  to  network  response. 

2.1.2  Network  call  states 

The  call  states  that  may  exist  on  the  network  side  of  the  user-network 
interface  are  defined  in  this  section. 

2. 1.2.1  Null  ( State  NO) 

No  call  exists. 

2.1. 2. 2  Dial  tone  sending  (Nl) 

This  state  exists  for  an  outgoing  call  when  the  network  sends  dial  tone 
prior  to  the  receipt  of  the  first  INFO  message. 

2. 1.2. 3  Overlao-sending  (N2) 

This  state  exists  for  an  outgoing  call  when  the  network  is  awaiting  further 
information  from  the  user  before  attempting  call  establishment. 

2.1. 2. 4  Call-sent  (Nil 

This  state  exists  for  an  outgoing  call  after  the  network  has  received  all 
the  information  required  to  proceed  with  call  establishment. 

2.1. 2.5  Call-delivered  (N4) 

This  state  exists  for  an  outgoing  call  when  the  network  is  aware  that 
compatible  user  equipment  exists  at  the  called  user  interface  which  can  accept  the  call. 

2. 1.2. 6  Negotiate  (N5) 

This  state  exists  for  an  incoming  call  when  the  user  and  the  network  are 
attempting  to  select  a  B-channel  on  which  to  complete  the  call. 

2. 1.2. 7  Call-oresent  (N6) 


This  state  exists  for  an  incoming  call  when  the  call  has  been  indicated  by 
the  network  but  no  user  has  indicated  whether  the  call  can  be  accepted. 

2. 1.2. 3  Call-received  (N7) 

This  state  exists  for  an  incoming  call  after  user  equipment  has  indicated 
the  start  of  user  alerting. 
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2. 1.2. 9  Connect  request  (W8j 

This  state  exists  when  an  incoming  call  is  awaiting  a  response  to  a  connect 
message  to  the  user. 

2.1.2.10  Active  (N9) 

This  state  exists  when  a  call  is  in  the  end-to-end  communication  mode. 

2.1.2.11  Dlsconnact-reouest  (N10) 

This  state  exists  after  a  user  has  indicated  disconnect  and  the  network  has 
not  yet  cleared  the  connection. 


2.1.2.12 


nect-lndication 


This  state  exists  when  the  network  has  indicated  disconnect  and  the  user  has 
not  yet  indicated  disconnect. 

2.1.2.13  Detach  (N12) 


This  state  exists  when  the  B-channel  has  been  released  but  the  call  has  not 
been  cleared  by  either  the  network  or  the  user. 

2.1.2.14  Suspend  request  (N13) 

This  state  exists  when  the  network  has  received  a  suspend  request  but  has  not 
yet  sent  a  response  to  the  user. 

2.1.2.15  Local  suspend  (Nil) 

This  state  exists  when  the  network  has  positively  acknowledged  a  request  for 
call  suspension. 


2.1.2.16 


request  (HI 


This  state  exists  when  the  network  has  received  a  resume  request  but  has  not 
yet  sent  a  response  to  the  user. 

2.1.2.17  Tone  active  (N16) 

This  state  exists  after  a  network  disconnect  request  when  the  option  of 
sending  in-band  tone  is  used. 

2.1.2.18  Release  request  (K17) 


This  state  exists  when  the  network  has  initiated  the  release  of  user  equip¬ 
ment  and  is  awaiting  user  acknowledgement. 

2.1.2.19  Remote  facility  request  (N18) 

This  state  exists  after  a  request  from  the  network  for  the  activation  of  a 
facility,  prior  to  user  response. 
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3.  Massage  functional  definitions 

3.1  Overview 

The  massage  functional  definitions  are  listed  in  alphabetical  order. 

Each  definition  includes  : 

a)  a  brief  description  of  the  message  direction  and  use; 

b)  a  figure  listing  the  information  elements  contained  in  the  message.  For 
each  information  element,  the  figure  indicates  : 


1)  the  section  of  this  Recommendation  describing  the  information  element; 

2)  the  direction  in  which  it  may  be  sent;  i.e.,  user  to  network  ('u  n') 

network  to  user  ('n  u' )  or  both; 

3)  whether  inclusion  is  mandatory  ( *M* )  or  optional  ('0'); 

4)  the  length(s),  in  octets.  •?•  means  the  maximum  length  is  undefined. 

The  information  elements  are  listed  in  order  of  appearance  in  the  message. 

The  relative  order  of  information  elements  is  the  same  for  all  message  types. 

Note  -  All  messages  may  contain  network-specific  information  elements  and  these  have  not 
been  included  in  any  of  the  figures  in  section  3. 

c)  further  explanatory  notes,  as  necessary. 

3.2  Messages  for  circuit-mode  connections 

Figure  3-1/Q.930  summarizes  the  messages  and  their  contents. 

3.2.1  AT.EBTi  ng 

This  message  is  sent  by  the  called  user  to  the  network,  and  by  the  network 
to  the  calling  user,  to  indicate  that  called  user  alerting  has  been  initiated. 

This  message  is  sent  by  called  stimulus  terminals  to  indicate  that  it  has 
received  the  SETUP  message,  (see  Figure  3-2/Q.930). 


:: 


•?: 

•V 

.*.1 

1 


sj 


Message  type  :  ALERTing 
Direction  :  both 


Information  element 


Protocol  discriminator 


Call  reference 


Message  type 


CCITT-standardized  facilities 


Network-specific  facilities 


terminal  capabilities 


Display- 


Redirecting  address 


User-user  information 


4.5.26 


Rote  1  -  User-user  information  may  be  included  for  outgoing  calls  and  when  an 
incoming  call  was  offered  with  the  point-to-point  procedure.  Further  study  is 
needed  on  whether  user-user  information  may  be  included  for  incoming  calls  offered 
with  point- to  multipoint  procedures. 

Note  2  -  The  maximum  length  of  the  user-user  information  element  is  network 
dependent  and  is  either  34  or  130  octets. 


this  message  is  sent  by  the  network  to  indicate  failure  of  a  facility 
dlsconnetion  (see  Figure  3-3/Q .930) . 


v  •  -  v;Xv:v;.;.:v 
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Message  type  :  CANCel  REJect 
Direction  :  network  to  user 


Information  element 
Protocol  discriminator 
Call  reference 
Message  type 
Cause 


Reference  Direction 


4-2 

4.3 

4*4 

4.5.8 


n  u 

n  u 
n  -*■  u 
n  -►  u 


Length 

1 

1  -  ? 

1 

3  -  ? 


Note  -  The  inclusion  of  other  information  elements  is  for  further  study. 


CANCel  REJect  message  content 


3-2.3  CONgestlon  CONtrol 

This  message  is  sent  by  the  network  to  indicate  the  establishment  or 
termination  of  flow  control  on  the  transmission  of  DSERINPO  messages  (see 
Figure  3-4/Q.930). 

Note  -  The  ability  for  the  user  to  send  this  message  to  the  network  is  for 
further  study. 

Message  type  :  CONgestlon  CONtrol 
Direction  :  See  note 


Information  element 
Protocol  discriminator 
Call  reference 
Message  type 
Congestion  level 
Cause 
Display 


Note  -  The  ability  for  the  user  to  send  this  message  to  the  network  is  for 
further  study. 


Reference 

Direction 

4.2 

See  Note 

4.3 

See  Note 

4.4 

See  Note 

4.5.12 

See  Note 

4.5.8 

See  Note 

4.5.15 

See  Note 

Length 

1 

1  -  ? 

1 
1 
3  - 
3  -  ? 
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This  message  is  sent  by  the  network  to  a  user  to  indicate  that  requested 
call  establishment  has  been  initiated,  and  no  more  call  establishment  information 
will  be  accepted  from  the  user  (see  Figure  3-5/Q.930) . 


Message  type  :  CALL  SENT 
Direction  :  network  to  user 


Information  element 


Protocol  discriminator 


Call  reference 


Message  type 


Channel  identification 


Display 


Reference 


4.5.10 


4.5.15 


Direction 

Type 

n  u 

M 

n  -*■  u 

M 

n  -*■  u 

M 

n  *  u 

M 

Length 


This  message  is  sent  by  the  network  to  indicate  disconnection  of  a 
facility  (see  Figure  3-6/Q.930) . 


Message  type  :  CANCellation  Acknowledge 
Direction  :  network  to  user 


Informat: 


Protocol  discriminator 


Call  reference 


Message  type 


Note  -  The  inclusion  of  other  Information  elements  is  for  further  study 


n  •*  u 


n  -*■  u 


This  message  is  sent  by  the  called  user  to  the  network  and  by  the  network 
to  the  calling  user  to  indicate  call  acception  by  the  called  user 
(see  Figure  3-7/Q.930). 

Message  type  :  CONNect 
Direction  :  both 


Information  element 

Reference 

Direction 

Type 

Length 

Protocol  discriminator 

4.2 

both 

FM 

1 

Call  reference 

4.3 

both 

VM 

1  -  ? 

Message  type 

4«4 

both 

FM 

1 

Connected  address 

4.5.13 

both 

0 

4  -  ? 

CCITT-standardized  facilities 

4.5.9 

both 

0 

3  -  ? 

Network-specific  facilities 

4.5.19 

both 

0 

3  -  ? 

Terminal  capabilities 

4-5.24 

n  -►  u 

0 

mam 

Display 

4.5.15 

n  ♦  u 

0 

mum 

Redirecting  address 

4.5.21 

both 

0 

4  -  ? 

User-user  information 

4.5.26 

both 

0 

See  Note  2 

Note  1  -  The  inclusion  of  bearer  service  and  compatibility  for  negotiation  of  call 
characteristics  at  establishment  is  for  further  study. 

Note  2  -  The  maximum  length  of  the  user-user  information  element  is  network 
dependent  and  may  be  34  or  130  octets. 

FIGURE  3-7/Q.930 
CONNect  message  content 

3.2.7  CONNect  Acknowledge 


This  message  is  sent  by  the  network  to  the  called  user  and  may  be  sent 
by  the  calling  user  to  the  network  (see  Figure  3-8/Q.930). 


Note  -  34  or  130,  the  value  being  network  dependent 


DETach  message  contents 


3.2.10  Disconnect 

This  message  may  be  sent  by  either  the  network  or  the  user  to  initiate 
call  clearing  (see  Figure  3-11/Q.930). 
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Message  type  :  Disconnect 
Direction  :  both 


Information  element 


Protocol  discriminator 


Call  reference 


Message  type 


Cause 


Display 


User-user  information 


Reference 


4.5.8 


4.5.15 


4.5.12 


Direction 

Type 

both 

M 

both 

M 

both 

M 

both 

M 

n  -*•  u 


both 


Length 


3  -  ? 


3  -  ? 


3  -  tfote 


Note  -  34  or  130,  the  value  being  network  dependent 


Disconnect  message  contents 


This  message  is  sent  by  a  user  to  initiate  access  to  a  network  facility 
and  by  the  network  to  a  user  when  access  to  the  facility  requires  user  agreement 
(see  Figure  3-12/Q.930). 

Message  type  s  FACility 
Direction  :  both 


Information  element  Reference  Direction 


Protocol  discriminator  4.2  both 


Call  reference  4.3  both 


Message  type  4.4  both 


Origination  address  4.5.20  both 


CCITT-standardized  facilities  4.5.9  both 


Network-specific  facilities  4.5.19  both 


Display  4.5.15  n  •*  u 


Length 


See  Note  13- 


See  Note  1 


Note  1  -  Either  the  CCITT-standardized  facilities  or  network-specific  facilities 
information  element  oust  be  present. 

Note  2  -  The  inclusion  of  other  information  elements  is  for  further  study. 


This  message  is  sent  by  the  network  to  indicate  attachment  of  a 
requested  facility  to  a  call,  and  by  a  user  to  indicate  agreement  to  attachment 
of  a  network  facility  to  a  call  (see  Figure  3-13/Q.930). 

Message  type  :  FACility  ACRnowledge 
Direction  :  both 


Information  element 


Protocol  discriminator 


Call  reference 


Message  type 


Display 


Reference 

4.2 

4.3 
4*4 

4.5.15 


Direction 


both 


both 


both 


n  u 


Type 

M 


M 


M 


0 


Length 


1 


1  -  ? 


1 


3  -  7 


Note  -  The  inclusion  of  other  information  elements  is  for  further  study. 

FIGURE  3-13/Q.930 

FACility  ACRnowledge  message  content 
3-2.13  FACility  CANCel 

This  message  is  sent  by  a  user  to  indicate  41s conme^*. ion  ?r  *  facility 
(see  Figure  3-14/Q-930). 

Message  type  s  FACility  CANCel 
Direction  :  user  to  network 


Information  element 

Reference 

yi  r+~ 

Protocol  discriminator 

4.2 

l 

L- 

Call  reference 

4.3 

— 

*  • 

Message  type 

4-4 

.  • 

CCITT-standardized  facilities 

4.5.9 

4  • 

Network-specific  facilities 


4.5.19 


-  29  - 
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3.2.14  FACility  REGister 

This  message  is  sent  by  a  user  to  initiate  registration  to  a  network 
facility,  and  by  the  network  to  a  user  when  registration  requires  user  agreement 
(see  Figure  3-15/Q.930). 

Message  type  :  FACility  REGister 
Direction  :  both 


Information  element 

Reference 

Direction 

Type 

Length 

Protocol  discriminator 

4.2 

both 

M 

1 

Call  reference 

4.3 

both 

M 

1  -  ? 

Message  Type 

4.4 

both 

M 

1 

CCITT-standardized  facilities 

4.5.9 

both 

See  Note  1 

3  -  ? 

Metwork-specific  facilities 

4.5.19 

both 

See  Note  1 

3  -  ? 

Note  1  -  Either  the  CCITT-star.dardiced  facilities  or  the  network-specific 
facilities  information  element  must  be  present. 

Mote  2  -  The  inclusion  of  other  information  elements  is  for  further  study. 

FIGURE  3-15/0.930 
FACility  REGister  message  contents 
3.2.15  FACility  REJect 

This  message  is  sent  from  the  network,  or  a  user,  to  indicate  failure 
of  a  facility  request  (see  Figure  3-1 VQ .930) . 

Message  type  :  FACility  REJect 
Direction  :  both 


Information  element 

Reference 

Direction 

Type 

Length 

Protocol  discriminator 

4.2 

both 

M 

1 

Call  reference 

4.3 

both 

M 

1  -  ? 

Message  type 

4.4 

both 

M 

1 

Cause 

4-5.8 

both 

M 

3  -  ? 

Display 

n  -*•  u 

0 

3  -  ? 

Mote  -  The  Inclusion  of  other  information  elements  is  for  further  study. 

FIGURE  3-16/0.030 

FACility  REJect  message  content 
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3.2.16  INFOrmation 

This  message  is  sent  from  the  user  to  the  network,  or  from  the  network  to 
the  user,  to  provide  additional  information.  It  may  be  used  to  provide  information 
for  call  establishment  (e.g.  direct-dialling-in  (DDI)),  identify  channels  in 
channel  negotiation,  and  to  request  and  provide  status  on  facilities. 

(see  Figure  3-17/Q.930). 

Message  type  :  INFOrmation 
Direction  :  both 


Information  element 

Reference 

Direction 

Type 

Length 

Protocol  discriminator 

m 

both 

M 

1 

Call  reference 

4.3 

both 

M 

1  -  ? 

Message  type 

4  «4 

both 

M 

1 

Channel  identification 

4.5.10 

both 

0 

mam 

Destination  address 

4.5.14 

both 

0 

4  -  ? 

Transit  network  selection 

4.5.25 

u  -►  n 

-_l 

0 

warn 

CCITT-standardized  facilities 

4.5-9 

u  -►  n 

0 

3  -  ? 

Network-specific  facilities 

4.5.19 

u  -*•  n 

0 

mam 

Display 

4.5.15 

n  -*•  u 

0 

mam 

Keypad 

4.5.16 

u  n 

0 

3  -  ? 

Keypad  echo 

4.5.17 

n  -*■  u 

0 

mam 

Signal 

4.5.22 

n  +  u 

0 

3  -  ? 

User-user  Information 

4.5.26 

u  n 

0 

3  -  Note  2 

'tote  1  -  The  need  to  include  the  compatibility  information  element  is  for  further 
study . 

Note  2  -  The  maximum  length  of  the  user-user  information  element  is  network 
dependent  and  may  be  34  or  130  octets . 

FIGURE  3-17/0.930 

INFOrmation  message  content 

ft 


3.2.17  REGister  Acknowledge 

This  aessage  is  sent  by  the  network  to  confirm  a  user  facility  registration 
and  by  a  user  to  indicate  agreement  with  a  facility  registration  when  required 
(see  Figure  3-18/Q.930). 

Message  type  :  REGister  ACKnowledge 
Direction  :  both 


Information  element 

Reference 

Direction 

Type 

Length 

Protocol  discriminator 

4.2 

both 

M 

1 

Call  reference 

4.3 

both 

M 

1  -  ? 

Message  type 

4.4 

both 

M 

1 

Display 

4.5.15 

n  -*•  u 

0 

3  -  1 

Note  -  The  inclusion  of  other  information  elements  is  for  further  study. 

FIGURE  3-18/Q.930 

REGister  ACKnowledge  message  content 
3.2.18  REGister  REJect 

This  message  is  sent  by  the  network  to  indicate  failure  of  a  registration 
requested  by  a  user,  and  is  sent  by  a  user  to  indicate  refusal  of  the  attachment 
of  a  facility  (see  Figure  3-19/Q.930). 

Message  type  :  REGister  REJect 
Direction  :  both 


Information  element 

Reference 

Direction 

Type 

Length 

Protocol  discriminator 

4.2 

both 

M 

1 

Call  reference 

4.3 

both 

M 

1  -  ? 

Message  type 

4*4 

both 

M 

1 

Cause 

4.5.8 

both 

M 

3  -  1 

Display 

4.5.15 

n  -►  u 

0 

3-7 

Note  -  The  inclusion  of  other  information  elements  is  for  further  study. 


FIGURE  3-19/Q.930 


REGister  REJect  message  content 


This  message  is  sent,  from  either  the  user  or  the  network,  to  complete  call 
clearing  (see  Figure  3-20/Q.930) . 

Message  type  :  RELease 
Direction  :  both 


Information  element 


Protocol  discriminator 


Direction 


Length 


Call  reference 


Message  type 


Network-specific  facilities 


Terminal  capabilities 


Display 


User-user  information 


4.5.26 


3  -  Note  1 


Note  1  -  The  maximum  length  of  user-user  information  element  is  network  dependent 
and  is  34  or  130  octets. 


3.2.20  RELeaae  ACKnowledge 

This  message  is  sent,  from  either  the  user  or  the  network,  to  indicate 
the  completion  of  call  clearing  (see  Figure  3-21/Q.930). 

Message  type  :  RELeaae  ACKnowledge 
Direction  :  both 


Information  element 


Protocol  discriminator 


Call  reference 


Message  type 


The  inclusion  of  other  information  elements  is  for  further  study 


Direction 

Type 

both 

M 

both 

M 

both 

M 

Length 


RELeaae  ACKnowledge  message  content 


This  message  is  sent  from  the  user  to  the  network  to  request  re-establish 
ment  of  a  suspended  call  (see  Figure  3-22/Q.930). 

Message  type  :  RESume 
Direction  :  user  to  network 


Information  element 


Protocol  discriminator 


Call  reference 


Message  type 


Call  identity 


Channel  identification 


Terminal  capabilities 


Reference 


.5.6 


4.5.10 


4.5.24 


Direction 


u  -*■  n 


u  -*■  n 


u  •*  n 


u  •*  n 


u  **•  n 


u  * 


Length 


Si 


'JJ 


i! 


3-2.22  RESume  ACKnowledge 

This  message  is  sent  by  the  network  to  the  user  to  indicate  completion 
of  a  request  for  call  re-establishment  (see  Figure  3-23/Q.930). 

Message  type  :  RESume  ACKnowledge 
Direction  :  network  to  user 


Information  element 


Protocol  discriminator 


Call  reference 


Message  type 


Channel  identification 


Reference 


Direction 

Type 

n  -►  u 

M 

n  -►  u 

M 

n  •+■  u 

M 

Length 


RESume  ACKnowledge  message  content 


3.2.23  RESume  HEJect 


This  message  is  sent  by  the  network  to  indicate  failure  to  complete  a 
requested  re-establishment  of  a  suspended  call  (see  Figure  3-24/Q.930). 

Message  type  :  RESume  REJect 
Direction  :  network  to  user 


Information  element 

Reference 

Directii 

Protocol  discriminator 

4.2 

n  •»  u 

Call  reference 

4.3 

n  ♦  u 

Message  type 

4.4 

n  -*■  u 

Cause 

4.5.8 

n  -**  u 

Length 
1 

1  -  ' 

1 

3  -  ■ 


RESume  REJect  message  content 


This  message  is  sent,  from  either  the  user  or  the  network,  to  indicate 
call  establishment  (see  Figure  3-25/Q.930). 

Message  type  :  SETUP 
Direction  :  both 


Information  element 

Reference 

Direction 

Type 

Length 

Protocol  discriminator 

4-2 

both 

M 

1 

Call  reference 

4-3 

both 

M 

1  -  ? 

Message  type 

4.4 

both 

M 

1 

Bearer  service  identification 

4.5.5 

both 

M 

3  -  ? 

Channel  identification 

4.5.10 

U  “  n 

-  u 

0 

3  -  ? 

CCITT-standardized  facilities 

4.5.9 

both 

0 

3  -  ? 

Network-soecifie  facilities 

4.5.19 

both 

0 

3  -  ? 

Terminal  capabilities 

u  n 

0 

3 

Display 

4.5.15 

n  u 

0 

3  -  ? 

Keypad 

4.5.16 

u  -*•  n 

0 

3  -  ? 

Signal 

4.5.22 

n  -*•  u 

0 

3  -  ? 

Origination  address 

4.5.20 

both 

0 

4  -  ? 

Destination  address 

4.5.14 

both 

0 

4-? 

Redirecting  address 

4.5.21 

n  u 

0 

4  -  ? 

Transit  network  selection 

4-5.25 

u  n 

0 

3  -  ? 

Compatibility 

4.5.11 

both 

0 

3  -  ? 

User-user  Information 

4.5.26 

both 

0 

3  -  Note  1 

Note  1  -  The  maximum  length  of  user-user  information  element  is  network  dependent 
and  is  34  or  130  octets. 


Note  2  -  The  bearer  service  and  compatibility  information  elements  may  be  used  to 
describe  a  CCITT  telecommunications  service,  if  appropriate. 


3.2.25  S&TUP  ACKnowlegge 


This  message  is  sent  by  the  network  to  the  calling  user,  and  by  the  called 
user  (on  a  primary  interface  structure)  to  the  network,  to  indicate  call  establish¬ 
ment  has  been  initiated  but  will  not  proceed  until  additional  information  is 
exchanged  (see  Figure  3-26/Q.930). 


Message  type  :  SETUP  ACKnowledge 
Direction  :  both 


Information  element 


Reference 


Direction 


Length 


Protocol  discriminator 


Call  reference 


Message  type 


Channel  identification 


4.5.10 


CCITT-standardized  facilities 


Network-specific  facilities 


4-5.19 


Display 


4.5.15 


Signal 


4.5.22 


3.2.26  STATUS 


This  message  may  be  sent  from  either  the  user  or  the  network  at  any  time 
during  a  call  when  an  unexpected  message  is  received  or  to  report  other  conditions 
of  the  call  (see  Figure  3-27/Q.930). 


Message  type  ;  STATUS 
Direction  :  both 


Information  element 


Reference 


Direction 


Length 


Protocol  discriminator 


Call  reference 


Message  type 


Call  state 


4.5.7 


STATUS  message  content 


A. 256 


-  37  - 

3.2.27  SUSPend 

This  message  is  sent  from  the  user  to  request  suspension  of  a  call 
(see  Figure  3-28/Q.930). 

Message  type  s  SUSPend 
Direction  :  user  to  network 


Information  element 

Reference 

Direction 

Type 

Length 

Protocol  discriminator 

4.2 

u  -*•  n 

M 

1 

Call  reference 

4.3 

u  -*■  n 

M 

1  -  ? 

Message  type 

4  *4 

u  ■*  n 

M 

1 

Call  identity 

4.5.6 

u  -*■  n 

0 

3  -  ? 

FIGURE  3-28/0.  .930 


SUSPend  message  content 

3.2.28  SUSPend  ACKnowledge 

This  message  is  sent  from  the  network  to  the  user  to  indicate  completion 
of  a  requested  suspension  of  a  call  (see  Figure  3-29/Q.930). 

Message  type  :  SUSPend  ACKnowledge 
Direction  J  network  to  user 


Information  element 

Reference 

Direction 

Type 

Length 

Protocol  discriminator 

4.2 

n  -*■  u 

M 

1 

Call  reference 

4.3 

n  -*■  u 

M 

1  -  ? 

Message  type 

4.4 

n  -*■  u 

M 

1 

Display 

4.5.15 

n  u 

0 

3  -  ? 

FIGURE  3-29/Q.930 

SUSPend  ACKnowledge  message  content 
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3.2.29  SUSPend  REJect 

This  message  is  sent  from  the  network  to  the  user  to  indicate  failure 
of  a  requested  call  suspension  (see  Figure  3-30/Q.930). 

Message  type  :  SUSPend  REJect 
Direction  :  network  to  user 


Information  element 

Reference 

Direction 

Type 

Length 

Protocol  discriminator 

4-2 

n  -*■  u 

M 

1 

Call  reference 

4-3 

n  -*■  u 

M 

1  -  ? 

Message  type 

4.4 

n  ♦  u 

M 

1 

Cause 

4.5.8 

n  u 

M 

3  -  ? 

Display 

4.5.15 

n  -*•  u 

0 

3  -  ? 

SUSPend  REJect  message  content 

3.2.30  USER  INFOrmation 

This  message  is  sent  by  a  user  to  the  network  to  transmit  information  to 
another  user,  and  by  the  network  to  a  user  to  deliver  information  from  another 
user  (see  Figure  3-31/Q-930). 

Message  type  :  USER  INFOrmation 
Direction  :  both 


Information  element 
Protocol  discriminator 
Call  reference 
Message  type 
More  data  indication 
Display 

User-user  information 


Note  -  Either  display  or  user-user  information  element,  but  not  both,  must  be 
present. 

FIGURE  3-31/0.930 
USER  INFOrmation  message  content 


Reference 

Direction 

Type 

Length 

4.2 

both 

M 

1 

4.3 

both 

M 

1  -  ? 

4.4 

both 

M 

1 

4.5.18 

both 

0 

1 

4.5.15 

n  -*■  u 

See  Note 

3  -  ? 

4.5.26 

both 

See  Note 

3-34 

»V.. 


.  "v  v.v  \\>V  V 
U  V  V  v 


♦“  V 


V.V, 


\.y 
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3.3 


Messages  for  other  types  of  connections 


No te  -  Other  types  of  circuit-node  connections  include  leased  connections  as  well  as 
connections  whose  establishment/clearing  may  not  occur  immediately  following  the 
relevant  user-to-network  signalling.  The  exact  terminology  for  tnese  other  types  of 
connections  is  for  further  study  by  CCITT. 


3.3.1'  The  following  messages,  defined  in  section  3*2  are  used  for  temporary 
user-to-user  signalling  connections  : 


a) 

b) 

c) 


ALERTing 
CALL  SENT 

CONGestion  CONTrol 

d)  COKNect 

e)  CONNect  ACKnowledge 
Disconnect 
RELease 

RELease  ACKnowledge 

i)  SETUP 

j )  STATUS 

k)  USER  INFOrmation 


f) 

«) 

h) 


Note  -  The  need  for  possible  changes  in  the  contents  of  these  messages  is  for  further 
study. 


3.3.2  The  following  messages,  defined  in  section  3.2  are  used  for  permanent  user- 
to-user  signalling  connections  : 


a)  CONGestion  CONTrol 

b)  STATUS 

c)  USER  INFOrmation 


Note  -  The  need  for  possible  changes  in  the  contents  of  these  messages  is  for  further 
study. 


3.3.3  The  following  messages,  defined  in  section  3.2  are  used  for  the  support  of 
Recommendation  X.25  packet  mode  connections  via  the  D-channel  : 


a)  RELease 

b)  RELease  ACKnowledge 
SETUP 


■  V 


\  \  / 


V. 


f 

a 


n 


A 


££  ft 


yj 


t 


*■ 


. r?: 

-■.'.v.v.v-vJ 


d)  SETUP  ACiCnowledge 

e)  STATUS 


Note  -  The  need  for  possible  changes  in  the  contents  of  these  messages  is  for  further 
study. 


3.3.4  The  following  messages,  defined  in  section  3-2  are  used  for  support  of 
Recommendation  X.25  packet  mode  connections  via  the  B-channel  : 

a)  ALERTing 

b)  CALL  SENT 

c)  CONNect 

d)  CONNect  ACKnovledge 

e)  DETach 

f)  Disconnect 

g)  RELease 

h)  RELease  ACKnovledge 

i)  INFOrmation 
J )  SETUP 

k)  STATUS 

Note  -  The  need  for  possible  changes  in  the  contents  of  these  messages  is  for  further 
study. 

4  Mwage  structure 

The  figures  and  text  in  this  section  describe  message  contents . 

Within  each  octet,  the  bit  designated  "bit  1"  is  transnitted  first,  followed  by 
bits  2,  3,  4,  etc.  Similarly,  the  octet  shown  at  the  top  of  each  figure  is  sent 
first. 

4.1  Overview 

Within  this  protocol,  every  message  may  consist  of  the  following  oarts  : 

a)  OSI  network  layer  protocol  discriminator? 

b)  call  reference; 

c)  message  type? 

d)  mandatory  information  elements,  as  required; 

9)  additional  information  elements,  when  required. 

Elements  a),  b)  and  c)  are  commnn  to  all  the  messages  and  must  always  be 
present,  while  elements  d)  and  e)  are  specific  to  each  message  type. 
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This  organization  is  illustrated  in  the  example  shown  in 
Fiqure  4-1/Q.930. 

A  particular  message  may  contain  more  information  than  a  particular 
equipment  needs  or  can  understand.  All  equipment  should  be  able  to  ignore 
any  extra  information,  present  in  a  message,  which  is  not  required  for  the 
proper  operation  of  that  equipment.  For  exanple,  a  TE  may  ignore  the 
originating  address  if  that  address  is  of  no  interest  to  the  'TO  when  a  SETTOP  is 
received. 

Unless  specified  otherwise,  a  particular  information  element  may  be  present 
only  once  in  a  given  message. 

A  particular  information  elstent  may  be  present,  but  empty.  For 
example,  it  is  allowed  to  send  a  destination  address  information  element  which 
is  of  zero  length.  This  should  be  interpreted  by  the  receiver  as  equivalent  to 
that  information  element  being  absent.  Similarly,  an  absent  information  element 
should  be  interpreted  by  the  receiver  as  equivalent  to  that  information  element 
being  empty. 


The  purpose  of  the  OSI  network  layer  protocol  discriminator  is  to 
distinguish  messages  for  user-network  call  control  from  other  messages  (to  be 
defined)  within  this  Recommendation .  It  also  distinguishes  messages  of  this 
Recommendation  from  those  OSI  network  layer  protocol  units  which  are  coded  to 
other  CCHT  Recommendations  and  other  standards. 

The  OSI  network  laver  protocol  discriminator  is  the  first  part  of 
every  messaqe.  'Fie  OSI  network  laver  protocol  discriminator  is  coded  according 
to  '•tours  4-2/C .* . 


7 - 

AD-A141  518 

UNCLASSIFIED 


CCITT  (INTERNATIONAL  TELEGRAPH  CONSULTATIVE  COMMITTEE)  4/4 
STUDV  GROUPS  XI  AN.  .  <U>  NATIONAL  CONNUNICATIONS  SVSTEH 
WASHINGTON  DC  F  N  MCCLELLAND  ET  AL.  DEC  82 
NCS-TIB-82-2  F/G  17/2  NL 


6 


5 


3 


2 


Q.930  user-network  call  control  messages 
0  0  0  0  1 
OSI  network-layer  protocol  discriminator 


0  0 


0 


Octet  1 


The  OSI  network  layer  protocol  discriminator  value  is  taken  from  the 
following  table: 


8  7  6  5  4  3  2  1 

0000  0000 

0  0  0  0  0  0  0  1  1 
through  (■ 

0  0  0  0  0  1  1  1  J 

0  0  0  0  1  0  0  0 

0  0  0  0  1  0  0  1  ] 

through  j 

0  0  0  0  1  1  1  1  ) 

0  0  0  1  0  0  0  0' 

through 

0  0  11  1111 

0  1  0  0  0  0  0  0 
through 

0  10  0  1111, 

0  1  0  1  0  0  0  0' 
through 

1111  1  1  1  0  J 

1111  1111 


reserved. 

reserved  for  other  network  layer  protocols. 

Q.930  (1.451)  user-network  call  control  messages 

reserved  for  other  messages  within  this 
Recommendation 

reserved  for  other  network  layer  protocols, 
including  X.25. 

national  use. 

reserved  for  other  network  layer  protocols,  including  X. 2! 
reserved  for  extension. 


FlOmffi  4-2/Q.930 


OSI  network  layer  protocol  discriminator 


np;T 


rj7»'^^-T5-J  ■J'j.  'J  "Ji  ->  .»V.‘y.7*y.T.V.rJ'i^.'?.J'-  ■**.  •'  •-■  *r-*  •-' 
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4-3  Call  reference 


The  purpose  of  the  call  reference  is  to  identify  the  call  or  facility 
registration/cancellation  request  at  the  local  user  network  interface  to  which  the 
particular  message  applies.  The  call  reference  does  not  have  end-to-end  significance 
across  ISDNs.  The  call  reference  is  assigned  at  the  beginning  of  a  call  and  remains 
fixed  for  the  lifetime  of  a  call  (except  during  suspension).  After  a  call  ends,  or 
after  successful  suspension,  the  associated  call  reference  value  may  be  reassigned  to 
a  later  call. 

The  call  reference  is  the  second  part  of  every  message.  The  call  reference 
is  coded  as  shown  in  Figure  4-3/Q.930.  The  call  reference  may  be  one  or  more  octets 
long. 


Call  reference  values  with  octet  2,  bit  8  set  to  "0"  are  assigned  by  the 
user  to  outgoing  calls.  These  call  reference  values  are  unique  only  for  a  particular 
D-channel  data  link  connection.  For  example,  assume  two  digital  telephone  TEls  are 
connected  in  a  bus  arrangement  to  an  interface  at  T.  Each  TE1  has  one  D-channel 
data  link  connection  with  the  network,  which  carries  the  signalling  messages  according 
to  this  Recommendation.  The  call  designated  with  the  call  reference  value  "0000  1110" 
on  one  data  link  connection  is  different  from  the  call  designated  with  the  same  call 
reference  value  on  the  other  data  link  connection. 

Call  reference  values  with  octet  2,  bit  8  set  to  "1"  are  assigned  by  the 
network  to  incoming  calls.  These  call  reference  values  are  unique  for  all  incoming 
calls  controlled  by  the  same  D-channel,  regardless  of  the  number  of  data  link 
connections  carrying  signalling  messages.  For  example,  again  assume  two  digital 
telephone  TEls  are  connected  in  a  bus  arrangement  to  an  interface  at  T.  Each  TE1  has 
one  D-channel  data  link  connection  with  the  network,  which  carries  the  signalling 
messages  according  to  this  Recommendation.  The  call  designated  with  the  call 
reference  value  "1000  0000"  on  one  data  link  connection  is  the  same  as  the  call 
designated  with  the  same  call  reference  value  on  the  other  data  link  connection. 

Note  -  The  dummy  call  reference  is  one  octet  long  and  is  coded  "0000  0000".  Uhen 
used,  it  replaces  the  call  reference  (octet  2)  and  is  placed  in  octet  1.  The  dummy 
call  reference  is  used  for  stimulus  operation,  and  in  some  other  cases  such  as 
certain  STATUS  messages. 


8  7  6  5  *  3  2  1 

1 

1  Length  of 

Octet  1 

0  0  0  01  call  reference 

|  value 

0  ■  ouc : 

1  -  in  j 

T*  Call  reference  value  - 

r 

1 _ _ _ 

etc 

FIGURE  4-3/Q.930 


Call  reference  information  element 
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4.4 


Message  type 


V*1 


.'•y> 


The  purpose  of  the  message  type  is  to  identify  the  function  of  the 
message  being  sent. 

The  message  type  is  the  third  part  of  every  message.  The  message  type 
is  ooded  as  shewn  in  Figure  4-4/Q.930. 

Bit  8  is  reserved  for  possible  future  use  as  an  extension  bit.  The 
coding  "1111  1111"  is  reserved  for  possible  future  use  as  an  extension 
indicator. 


•V' 


8 

7 

6 

5 

4 

3 

2 

1 

z 

;  message 

type 

Octet  1 

8 

7 

6 

5 

4 

3 

2 

_ l 

0 

0 

0 

- 

- 

- 

- 

- 

Call  establishment  messages: 

0 

0 

0 

0 

1 

-  ALERTing. 

0 

0 

0 

1 

0 

-  CALL  SENT. 

0 

0 

1 

1 

1 

-  CONNect. 

0 

1 

1 

1 

1 

-  CONNect  ACKnouledge. 

0 

0 

1 

0 

1 

-SETUP. 

0 

1 

1 

0 

1 

-  SETUP  ACKnovledge. 

0 

0 

1 

- 

_ 

_ 

- 

_ 

Call  lnformaiton  phase  messages: 

0 

0 

1 

1 

0 

-  RESume. 

0 

1 

1 

1 

0 

-  RESume  ACKnovledge. 

0 

•  0 

0 

1 

0 

-  RESume  REJect. 

0 

0 

1 

0 

1 

-  SUSPend. 

0 

1 

1 

0 

1 

-  SUSPend  ACKnovledge. 

0 

0 

0 

0 

1 

-  SUSpend  REJect. 

0 

0 

0 

0 

0 

-  USER  INFOrmation 

0 

1 

0 

_ 

_ 

_ 

_ 

_ 

Call  disestablishment  messages: 

0 

0 

0 

1 

0 

-  DELAYed  disconnect. 

0 

0 

0 

0 

0 

-  DETach. 

0 

0 

1 

0 

1 

-  Disconnect. 

0 

i 

i 

0 

1 

-  RELease. 

1 

1 

0 

1 

0 

-  RELease  ACKnovledge 

0 

1 

1 

— 

_ 

— 

. 

_ 

Miscellaneous  messages: 

0 

1 

1 

1 

0 

-  CANCel  ACKnovledge 

0 

0 

1 

1 

1 

-  CANCel  REJect 

0 

1 

0 

0 

1 

-  CONgestion  CONtrol 

0 

0 

0 

0 

0 

-  FACility 

0 

1 

0 

0 

0 

-  FACility  ACKnovledge 

0 

0 

1 

1 

0 

-  FACility  CANCel 

0 

0 

1 

0 

0 

-  FACility  REGister 

0 

0 

1 

0 

1 

-  FACility  REJect 

0 

1 

1 

0 

1 

-  INFOrmation 

0 

1 

1 

0 

0 

-  REGister  ACKnovledge 

0 

0 

1 

0 

1 

-  REGister  REJect 

0 

0 

0 

1 

1 

-  STATus 

MM 


m 

V, 


-V 

y 


?•% 


FIGURE  4-4/Q.930 
Message  types 
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4.5  Other  Information  elements 

4.5.1  The  codinq  of  other  information  elements  follows  the  oodinq  rules 
described  below.  These  rules  are  formulated  to  allow  each  equipment  which 
processes  a  message  to  find  information  elements  important  to  it,  and  yet 
remain  ignorant  of  information  elements  not  important  to  that  equiement. 

Two  categories  of  information  elements  are  defined: 

a)  single  octet  information  elenents  (see  Figure 

4-5  (a)  /Q.  930'); 

b)  variable  length  information  elements  (see  Figure 
4-5  (b)/Q.930) . 

For  the  information  elenents  listed  below,  the  coding  of  the 
information  element  idtentifier  bits  is  summarized  in  Figure  4-6/Q.930. 

The  descriptions  of  the  information  elements  below  are  organized  in 
alphabetical  order.  However,  there  is  a  particular  order  of  appearance  for  each 
information  element  in  a  message.  The  code  values  of  the  information  element 
identifier  for  the  variable  length  formats  are  assigned  in  ascending 
numerical  order,  according  to  the  actual  order  of  appearance  of  each 
information  element  in  a  message.  This  allows  the  receiving  equipment  to  detect 
the  presence  or  absence  of  a  particular  information  element  without  scanning 
through  an  entire  message. 

Information  elements  using  the  single  octet  information  element  identifier 
may  appear  at  any  point  in  the  message. 

Where  the  description  of  information  elements  in  thi3  Recommendation 
contains  3pare  bits,  these  bits  are  indicated  as  being  coded  to  "0".  In  order  to 
allow  compatibility  with  future  implementation,  messages  should  not  be  rejected 
simply  because  a  spare  bit  is  set  to  "1". 


Octet  1 


Information  j 

element  i 
identifier  < 


Contents  of 

information 

element 


(a)  Single  octet  information  element  format. 


Information  element  identifier  !  Octet  1 

l 

Length  of  Information  element  (octets)  2 

Contents  of  information  element  3 

(b)  Variable  length  information  element  format.  etc 

FI 0UR£  4-5/C. 91C 
Formats  of  Information  elements 


A. 265 


-  46  - 


3  7 

.6. 

±A JL 

2_ 

_1 

Section 

reference 

1  : 

: 

- 

- 

- 

- 

Sin2le  octet  information  elements: 

0 

0 

0 

- 

- 

- 

- 

reserved 

0 

0 

1 

- 

- 

- 

- 

shift 

4.5 

0 

1 

0 

0 

0 

0 

0 

more  data 

4.5.13 

0 

1 

1 

- 

- 

- 

- 

congestion  level 

4-5.12 

0  : 

; 

; 

: 

; 

• 

: 

Variable  leneth  information  element: 

0 

0 

0 

0 

1 

0 

0 

bearer  service  identification 

4-5.5 

0 

0 

0 

1 

0 

0 

0 

cause 

4.5.3 

0 

0 

0 

1 

1 

0 

0 

connected  address 

4.5.13 

0 

0 

1 

0 

0 

0 

0 

call  identity 

4.5.6 

0 

0 

1 

0 

1 

0 

0 

call  state 

4.5.7 

0 

0 

1 

1 

0 

0 

0 

channel  identification 

4.5.10 

0 

0 

1 

*1 

1 

0 

0 

CCITT-standardized  facilities 

4.5.9 

0 

l 

0 

0 

0 

0 

0 

network-specific  facilities 

4.5.19 

0 

1 

0 

0 

1 

0 

0 

terminal  capabilities 

4.5.24 

0 

1 

0 

1 

0 

0 

0 

display 

4.5.15 

0 

1 

0 

1 

1 

0 

0 

keypad 

4. 5. 16 

0 

1 

1 

0 

0 

0 

0 

keypad  echo 

4.5.17 

0 

1 

1 

0 

1 

0 

0 

signal 

4.5.22 

0 

1 

1 

0 

1 

1 

0 

switchhook 

4.5.23 

1 

1 

0 

1 

1 

0 

0 

origination  address 

4-5.2C 

1 

1 

1 

0 

0 

0 

0 

destination  address 

4.5.14 

1 

1 

1 

0 

1 

0 

0 

redirecting  address 

4.5.21 

1 

1 

1 

1 

0 

0 

0 

transit  network  selection 

4.5.25 

1 

1 

1 

1 

1 

0 

0 

compatibility 

4.5.11 

1 

1 

1 

1 

1 

1 

0 

user-user  information 

4.5.26 

1 

1 

1 

1 

1 

1 

1 

reserved  (escape) 

FIGURE  4- 6/0.930 

Information  element  identifier  coding 


4.5.2  There  are  136  possible  information  element  identifier  values  using  the 
formatting  rules  described  in  section  4-5.1  :  8  from  the  single  octet  information 
element  format  and  128  from  the  variable  length  information  element  format. 

One  value  in  the  single  octet  format  is  specified  for  shift  operations 
described  belorf.  One  other  value  in  both  the  single  octet  and  variable  format 
is  reserved.  This  leaves  133  information  element  identifier  values  available 
for  assigment. 

It  is  possible  to  expand  this  structure  to  eight  codesets  of  133 
information  element  identifier  values  each.  One  common  value  in  the  single 
octet  format  is  employed  in  each  codeset  to  facilitate  shifting  frcm  one 
codeset  to  another ,  The  contents  of  this  shift  item  identifies  the  codeset 
to  be  used  for  the  next  information  elenent  or  elements.  The  codeset  in  use  at 
any  given  time  is  referred  to  as  the  "active  codeset".  By  convention,  codeset  0 
is  the  initially  active  codeset. 

Two  codeset  shifting  procedures  are  supported:  locking  shift  and 
non-locking  shift. 

Codeset  6  Is  reserved  for  information  elements  specific  to  the  local 
serving  network. 

Codeset  7  is  reserved  for  user-specific  information  elements. 
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4.5.3  Locking  shift  procedure 

The  Locking  shift  procedure  emolovs  an  information  element  to 
indicate  the  new  active  codeset.  The  specified  codeset  remains  active  until 
another  locking  shift  information  element  is  encountered  which  specifies  the 
use  of  Mother  oodeset.  For  example,  codeset  0  is  active  at  the  start  of 
message  content  analysis.  If  a  locking  shift  to  oodeset  7  is  encountered,  the 
next  information  elements  will  be  interpreted  according  to  the  information 
elanent  identifiers  assigned  in  oodeset  7,  until  another  shift  information 
element  is  encountered. 

The  locking  shift  information  element  uses  the  single  octet 
information  element  format  and  coding  shown  in  Figure  4-7/Q.930. 


7 _ 6 _ 5 _ 4 

"  Shift  ;  T" 

:  0  0  1  ;  0  ; 

_j _ identifier  _ ! 

"0"  in  this  position 
indicates  locking  shift  — ■* 

Codeset  Identification  (bits  3  to  1) 


New  codeset 
identification 


,  Octet  1 


I.?..; 

000  codeset  0  (initially  active)  :  Q.930  (1.451)  information  elements 
0  0  1 

to  reserved 
10  1 

110  codeset  6  s  ipformation  elements  specific  to  the  local  serving  network 

111  codeaet  7  :  user-specific  information  elements 


Locking  shift  element 


4.5.4  Non-locking  shift  procedure 

The  non-locking  shift  procedure  provides  a  temporary  shift  to  the 
specified  codeset.  The  non-locking  shift  procedure  uses  a  single  octet 
information  element  to  indicate  the  oodeset  to  be  used  to  interpret  the  next 
single  following  information  element.  After  the  interpretation  of  the  next 
single  information  eleoent,  the  active  oodeset  is  again  used  for  interpreting 
any  following  Information  elements.  For  example,  oodeset  0  is  active  at  the 
beginning  of  message  content  analysis.  If  a  non-locking  shift  to  codeset  6  is 
encountered ,  only  the  next  information  element  is  interpreted  according  to 
the  information  element  identifiers  assigned  in  codeset  6.  After  this 
information  element  is  interpreted,  codeset  0  will  again  be  used  to  interpret 
the  follo/ing  information  elements. 

The  nan- locking  shift  information  element  uses  the  single  octet 
information  element  format  and  coding  shown  in  Figure  4.-3/Q.930. 
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8 _ 7 _ 6 _ 5 _ 4 _ 3 _ 2  1 


i  i 

•  i 

;  i  ; 

0 

Shift  ; 

o  i  ; 

1 

!  Temporary 
codeset 

J  Octet  1 

•  * 

identifier  < 

!  identification 

1 

"1"  in  this  posicion 
indicates  non-locking  shift 

Note  -  The  codeset  identification  is  coded  as  shown  in  Figure  4-7/Q.930. 

FIGURE  4-8/Q.930 
Non-locking  shift  element 
4-5-5  Bearer  service  identification 

The  purpose  of  the  bearer  service  identification  information  element  is 
to  indicate  a  requested  Recommendation  1.200  bearer  service. 

The  coding  included  in  this  section  is  provisional  and  is  a  subject  for 
further  study.  The  bearer  service  identification  information  element  is  coded  as 
shown  in  Figure  4-9a/Q.930.  The  bearer  service  identification  information  element 
may  be  repeated  in  a  message  to  identify  multiple  services,  e.g.,  in  individual 
transit  networks. 

No  default  bearer  service  may  be  assumed  by  the  absence  of  this 
information  element. 
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Bearer  service  identification 
0  0  1  0  0 
Information  element  identifier 

Length  of  the  bearer  service  identification 


0/1 

Ext 

Format  coding 
standard 

Access  format 

1 

Ext 

0  0 
Spare 

Multiplier 

o/i ; 

Ext 

Attribute  cod-  1 
ing  standard 

Operation 

mode 

Transfer 

mode 

1 

Ext 

Symmetry 

0 

Spare 

Configuratioi 

0/1 

Ext 

Rate  coding 
standard 

Beare] 

r  service  rate 

1 

Ext 

0  0 
Spare 

Multiplier 

Transparency 


0  0 
Spare 


Octet  1 


*  This  octet  may  be  omitted. 


earer  service  identification  information  element 


Extension  bit  (octets  3  through  5,  bit  8)  : 

0  access  format,  attributes  or  service  rate  description  continues  through 
next  octet 

1  last  octet  of  access  format,  attributes  or  service  rate  description 


bits 
7  6 

0  0  CCITT  standardized  in  this  Recommendation. 

0  1  reserved  foe.  other  international  standards. 

'.  0  national  standard. 

1  1  standard  specific  tc  rAtwor*  present  on  the  network  side 

•>.  the  interface. 


.  • .  ■  -  j 


.  *  .  a  ■>  *  *  . 
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Access  format  f  octet 

Bits 

Transparent 

Non-transparent  circuit- 

5  4  3  2  1 

circuit-mode 

mode  synchronous 

Other  synchronous 

0  0  0  0  0 

- 

- 

1.451  user-to-user 

0  0  0  0  1 

0.6  kbit/s 

voiceband  G.711  A-lawa^ 

X.25  protocol/0.6  kbit/s 

0  0  0  1  0 

1.2  » 

voiceband  G.711  p-lawa^ 

- 

0  0  0  1  1 

2.4  " 

voiceband  G.7zz  ADPCM 
(32  kbit/s )b' 

X.25  protocol/2.4  kbit/s 

0  0*1  0  0 

3.6  " 

- 

- 

0  0  10  1 

4.8  '* 

- 

X.25  protocol/4.8  kbit/s 

0  0  110 

7.2  " 

- 

- 

0  0  111 

8  " 

- 

- 

0  10  0  0 

9.6  « 

speech  G.7n  A-lawa^ 

X.25  protocol/9.6  kbit/s 

0  10  0  1 

14.4  " 

speech  G.7n  p-lawa^ 

- 

0  10  10 

16  " 

speech  G.7zz  ADPCM 
(32  kbit/s )b' 

- 

0  10  11 

19-2  " 

- 

- 

0  110  0 

32  » 

- 

- 

0  110  1 

- 

- 

.  - 

0  1110 

48  » 

- 

X.25  protocol/48  kbit/s 

0  1111 

56  " 

- 

- 

1  0  0  0  0 

1  0  0  0  1 

10  0  10 

64"  " 

digita^k^p^ech  G.711 

digital  speech  G.7n 
y-lawa)b)°) 

X.25  protocoi/64  kbit/s 

10  0  11 

384  kbit/s 

digital  speech  G.7zz  ADPCM 
(32  kbit/s)b)°) 

- 

110  0  1 

300  bit/sd) 

- 

- 

110  10 

200  " 

- 

- 

110  11 

150  " 

- 

- 

1110  0 

110  « 

- 

- 

1110  1 

75  " 

- 

- 

11110 

50  bit/sd) 

- 

- 

11111 

bearer  service  rate 

- 

a)  -  An 

ISON  win  support  either  A-law  or  y-law  values. 

The  support  of  the 

other  coding  law  is  a  matter  for  specific  national/network  determination. 

For  each  particular  network,  it  is  recommended  that  only  one  coding  law  be 
used.  But,  for  certain  special  national  circumstances,  a  network  is  allowed 
to  support  botn  coding  laws. 

b)  -  The  network  may  subject  "speech"  to  processing  suitable  for  human  speech 

communication  (e.g.  digital  speech  interpolation,  echo  cancellation,  very 
low  rate  speech  coding).  For  "voiceband"  communication,  processing  not 
suitable  for  modern  signals  will  not  be  performed  by  the  network. 

c)  -  Must  only  be  routed  via  digital  facilities. 

d)  -  These  are  asynchronous.  Other  rates  in  this  column  are  ail  synchronous. 


JLh 


« 


Bits  1  through  5  are  interpreted  as  a  binary  integer,  n,  indicating  that  the 
actual  bearer  service  rate  or  access  format  is  n  times  the  value  given  in  the  previous 
octet.  Bit  1  is  the  least  significant  bit  (2°). 

For  transparent  operations,  the  resulting  rate  is  to  be  considered  a 
transparent  aggregate  of  the  bearer  service  rate  or  access  rate.  For  non-transparent 
operations,  the  result  is  a  bundle  of  n  independent  paths  at  the  specified  rate. 

If  octet  3a  or  3a  is  omitted,  the  value  of  n  is  assumed  to  be  1. 

Hote  -  The  ability  to  indicate  bundles  of  independent  transparent  paths  i3  for 
further  study. 

Operation  mode  (octet  4)  : 

Bit 

i 

0  synchronous  operation 

1  asynchronous  operation 

Bote  -  If  octet  4  is  omitted,  synchronous  operation  is  assumed. 

Transfer  mode  (octet  4)  : 

Bits 

4J_ 

0  0  circuit  mode 

1  0  packet-mode 

All  other  values  are  reserved  for  further  study 
Note  -  If  octet  4  is  omitted,  the  transfer  mode  is  assumed  to  be  circuit-mode. 


Bits 

2_1 

0  0  non-transparent  services 

1  0  transparent  service 

All  other  values  are  reserved  for  further  Study- 
Note  -  If  octet  4  Is  omitted,  non-transparent  services  are  assumed. 


0  0  duplex 

0  1  this  value  is  reserved  for  further  study 

1  0  simplex-outgoing 

1  1  simplex  incoming 

Note  -  If  octet  4a  is  omitted,  the  symmetry  is  assumed  to  be  duplex. 


Bits 

kJ. 

0  0  point-to-point 

1  0  multipoint 

All  other  values  are  reserved  for  further  study 
Note  -  If  octet  4a  is  omitted,  the  configuration  is  assumed  to  be  point-to-poin.. 


Bearer  service  rate  (octet 


0  0  0  0  1 
0  0  0  1  1 
0  0  10  1 

00111  8  kbit/s 

0  10  0  0 

01010  16  kbit/s 

01100  32  kbit/s 

0  1110 

10000  64  kbit/s 

10011  384  kbit/s 

All  other  values  are  reserved  for  further  study. 


Circuit-mode 

Packet-mode 

rate 

throughput 

0.6  kbit/s 
2.4  kbit/s 
4-8  kbit/s 

9*6  kbit/s 
48  kbi  t/ s 


Note  -  If  octet  5  is  omitted,  the  full  rate  (e.g.  64  kbit/s  for  a  B-channel)  is 
assumed  to  apply 


Coding 

standard 


0  10  0 

0  0  0  0 

Access  format 


0  Octet  1  Defaults 


circuit-mode 

non-transparent  services 
point-to-point  configuration 
duplex  connection 
synchronous  operation 


Coding 

standard 


Access  format 


0  1 
0  2 


Defaults  :  point-to-point  configuration 
duplex  connection 


Coding 

standard 


Op  Mode  I  Transp  J  4 


No  default  values  assumed 


Coding 

standard 


Access  format 


Coding 

standard 


Op  Mode 


Transp. 


Symmetry  0  j  Configur.  0  0  4a 


Coding 

standard 


Bearer  service  rate 


•indicates  where  multiplier  may  be 
present 


Sxamoles  cf  bearer  service 


■Wv 


A 


4. 5. 6  Call  identity 

The  purpose  of  the  call  identity  information  element  is  to  identify  the 
suspended  call.  The  call  identity  provided  by  the  user  is  guaranteed  by  the  network 
to  be  unique  over  a  domain  of  interfaces  where  the  call  may  be  resumed.  The  call 
identity  is  assigned  at  the  start  of  the  call  suspension,  and  is  available  for  re-use 
after  the  resume  procedure  has  completed  successfully. 

The  call  identity  information  element  is  coded  as  shown  in  Figure  4-1/Q-930 


Call  identity 


information  element  identifier 


length  of  call  identity 


call  identity 
(any  pattern  allowed) 


Octet  1 


Call  state 


information  element  identifier 


length  of  call  state  value 


cal],  state  value 
(See  Note) 


Octet  1 


i 

call  init 

dial  tone  sending 

2 

overlap  sending 

overlap  sending 

3 

call  sent 

call  sent 

4 

dall  delivered 

call  delivered 

5 

negotiate 

negotiate 

6 

- 

call  present 

7 

call  received 

call  received 

8 

connect  request 

connect  request 

9 

active 

active 

10 

disconnect  request 

disconnect  request 

U 

disconnect  indication 

disconnect  Indication 

12 

detach 

detach 

13 

suspend  request 

suspend  request 

14 

local  suspend 

local  suspend 

15 

resume  request 

resume  request 

16 

- 

tone  active 

17 

- 

release  request 

18 

remote  facility  request 

remote  facility  request 

19 

local  facility  request 

local  facility  request 

Sots  -  The  call  state  value  Is  the  binary  coding  of  the  state  number,  with 
bit  1  as  the  least  significant  bit  (2°). 

^654321 


Cause 


Diagnostics 


0  0 

0  0  0 

0 

1 

0  0 

0  0  0  1 

0 

0  0 

0  0  0  1 

1 

0  0 

0  0  10 

0 

0  0 

0  0  10 

1 

0  0 

0  0  11 

0 

0  0 

0  0  11 

1 

0  0 

0  10  0 

0 

0  0 

0  10  0 

0 

0  0 

0 

10  1 

0 

0  0 

1 

0 

0 

0 

0 

0  0 

1 

0 

0 

0 

1 

0  0 

1 

0 

0 

1 

1 

0  1 

0 

0 

0 

0 

0 

0  1 

0 

0 

0 

0 

1 

0  1 

0 

0 

0 

1 

0 

0  1 

0 

0 

0 

1 

1 

0  1 

0 

0 

1 

0 

0 

0  1 

1 

0 

0 

0 

0 

0  1 

1 

0 

0 

0 

1 

0  1 

1 

0 

0 

1 

0 

0  1 

1 

0 

0 

1 

1 

0  1 

1 

0 

1 

0 

0 

0  1 

1 

0 

1 

0 

1 

0  1 

1 

0 

1 

1 

0 

0  1 

1 

0 

1 

1 

1 

0  1 

1 

1 

0 

0 

0 

0  1 

1 

1 

0 

0 

1 

0  1 

1 

1 

0 

1 

0 

0  1 

1 

1 

0 

1 

1 

0  1 

1 

1 

1 

0 

0 

0  1 

1 

1 

1 

0 

1 

0  1 

1 

1 

1 

1 

0 

1  0 

0 

0 

0 

0 

0 

1  0 

0 

0 

0 

0 

1 

1  0 

0 

0 

0 

1 

0 

1  0 

1 

0 

0 

0 

0 

1  0 

1 

0 

0 

0 

1 

1  0 

1 

0 

0 

1 

0 

10  1 

0 

0 

1 

1 

10  1 

0 

1 

0 

0 

invalid  call  reference  value 
message  sot  lnpleaented 
bearer  service  not  lnpleaented 
connection  type  not  Implemented 
channel  type  sot  implemented 
Identified  channel  does  not  exist 
call  identity  does  not  exist 
call  Identity  In  use 
overlap  sending  not  alloved 
no  channel  available 
requested  facility  not  lnpleaented 
requested  facility  not  subscribed 
Invalid  facility  paraaeter 
outgoing  calls  barred 
outgoing  calls  barred  within  CDS 
(orlg.) 

Incoming  calls  barred  within  CTO 
(dost. ) 

non-existent  closed  user  group 
destination  address  not  amber  of  TOG 
reverse  charging  not  allowed 
(at  orlg.  end) 

reverse  charging  not  allowed 

(at  daat.  end) 

reverse  charging  rejected 

Incompatible  destination 

non  existent  abbreviated  address 

entry 

destination  not  obtainable 
destination  address  missing,  and 
direct  call  not  subscribed 
this  cell  malting  at  destination 
rasher  changed 
out  of  order 
no  uaar  responding 
user  busy 

call  welting  not  subscribed 
Incoming  calls  bazrsd 
call  rejected 
degraded  service  (e.g. , 
excessive  error  rate) 
circuit  out-of-order 
circuit  operational 
transit  network  out  of  order 
transit  network  selection  not 
Implemented 

transit  network  does  not  exist 
transit  daisy  range  cannot  ba 
achieved 

throughput  range  cannot  bo 
achieved 
network  failure 
network  congestion 
remote  uaar  Initiated 


call  ref.  value 
message  type 
service  .  yr 

channel  type 
channel  ID 
call  identity 
call  Identity 

network  id,  facility 
network  id,  facility 
network  id,  facility 

CTO,  id. 

TOG  id,  dest.  address 
CTO  number 

daat.  address,  TOG  number 


dest.  address  Incompatible  paraaeter 
copy  of  address  element 

daat.  address 


dest.  address 

dest.  address,  new  daat.  address 

daat.  address 

daat.  address 

daat.  address 

daat.  address 

daat.  address  optional  user- specified  info 
user- supplied,  diagnostic 


circuit  id. 
circuit  id. 
transit  network  id. 


transit  network  id. 

min.  available  transit  delay 

max.  available  throughput 

dost,  address 

network  id. 
remote  user  address 

remote  user-supplied  cause  Info 


0  110  0  0 
0  110  0  1 
0  110  10 


Cause  value 


7  6  5  4  3  2  1 


Diagnostics 


1100000  X.21  DTE  controlled-not-ready 
1100001  X.21  DTE  uncontrolled-no t- ready 
1100010  PAD  clearing 
1100011  time-out. on  start  of  X.25  data 
1  1  0  0  1  0  0  packet  size  not  available 
1100101  packet  window  size  not  available 
1110000  local  procedure  error 
1110001  remote  procedure  error 
1110010  remote  user  suspended 
1110011  remote  user  resumed 
1111111  user  INFO  discarded  locally 


dest.  address 


dest.  address 


copy  of  erroneous  message 


user  address 
user  address 

copy  of  first  32  octets  of 
user-user  information  element 


(continuation) 


The  purpose  of  the  CCITT-s tarn ardi zed  facilities  information  element  is  to 
indicate  which  CCITT-atandardized  binary  facilities  are  being  invoked.  "Binary 
facilities"  are  those  which  do  not  require  a  parameter.  Parameterized  facilities  are 
invoked  as  separate  information  elements. 

The  facilities  information  element  is  coded  as  shown  in  Figure  4-14/Q.930. 

The  facilities  are  given  in  Figure  4.14/Q-930.  This  figure  also  identifies 
which  facilities  may  be  invoked  on  a  per- call  basis,  and  which  may  be  invoked  to  apply 
continuously  to  all  interface  operations  after  invocation. 
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*L  S' 


CCITT-standardized  facilities 


Oil  1  0  1  0  0  0 

l 

•  information  element  identifier 

_ i _ 

Length  of  CCITT-standardized  facilities  information 

CCITT-standardized  facilities 
(See  Note  4) 


Octet  1 


2 

3  etc. 


per  contin- 
cal 1  uoua 


CCITT-stadardized  facility  Invoked  when  set  to  "l" 


x 

X 

X 

X 

X 

X 

X 

X 

X 


X 

X 

X 

X 

X 


X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

FS 

X 

X 


Delivery  of  origination  address  barred. 

Connected  address  required. 

Supply  charging  information  after  end  of  call. 
Reverse  charging  requested. 

Connect  outgoing  calls  when  free. 

Reverse  charging  acceptance  (allowed). 

Call  redirection/diversion  notification.  Note  3 
Call  completion  after  busy  request. 

Call  completion  after  busy  indication. 

Origination  address  required  on  outgoing  calls. 
Origination  address  desired  on  incoming  call. 
Destination  address  required  on  incoming  calls. 
Connect  incoming  calls  when  free  (waiting  allowed). 
X.25  extended  packet  sequence  numbering  (modulo  128) 
X.25  flow  control  parameter  negotiation  allowed. 

X.25  throughput  class  negotiation  allowed. 

X.25  packet  retransmission  (allowed). 

X.25  fast  select  (outgoing)  (allowed). 

X.25  fast  select  acceptance  allowed. 

X.25  multilink  procedure 

Local  charging  prevention 

X.25  extended  frame  sequence  numbering 


Note  1  -  Names  used  to  describe  the  above  facilities  are  provisional.  Final  choice 
of  facility  name  and  definition  is  for  further  study. 


Note  2  -  Other  facilities  are  for  further  study. 

Note  3  -  Classification  of  similarities  and  differences  between  redirection  and 
diversion  is  for  further  study. 

Note  4  -  The  coding  of  this  information  element  is  for  urgent  further  study. 

FIGPRE  4-14/Q.930 

CCITT-standarduzed  facilities  information  element 


4-5*10  Channel  identification 


The  purpose  of  the  channel  identification  information  element  is  to 
identify  a  channel  or  subchannel  within  the  interfaced )  controlled  by  these 
signalling  procedures. 


The  channel  identification  information  element  is  coded  as  shown  in 
Figure  4-15/Q.930.  The  channel  identification  information  element  may  be  repeated  in 
a  message;  e.g.  to  list  several  acceptable  channels  during  channel  negotiation. 


8 


Channel  identification 

0 

0  1 

1 

10  0  0 

information  element  identifier 

Length  of  channel  Identification 

0/1 

Ext 

Int  '  Int 

< 

id  1  type 

0  : 

spare  j 

- 1  i 

Pref/  J  D-ch  <  Info  chan 

/ Excl  1  ind  !  selection 

1  > 

1 

Ext 

Symmetry 

0 

OOOO! 

Spare 

0/1 

Ext 

Interface  identifier 

0/1 

Ext 

Coding 

standard 

_ 

ja. _ 

Channel  type/ 

/Map  element  type 

Channel^ /Slot  map 

I  0/1 

•  Ext 

Coding 

standard 

1 

Channel  type/ 

/ top  element  type 

1  Sub-channel  44-  /Sub-slot  map 

I.  ■ 

Note  1  =, 

Octet  1 


3a* 

3b* 


Note  2 


5a* 

5b* 


Note  1  -  Same  formats  cm  be  repeated  to  indicate  the  sub-unit  (e.g.  sub-sub-channel) 
of  the  unit  indicated  by  the  preceding  format  (e.g.  sub-channel). 


Note  2  -  This  information  is  replaced  by  "channel  selection"  in  Octet  3,  and  is 
omitted,  when  "Interface  type"  in  Octet  3  is  "basic  interface". 


Note  3  -  Octets  with  *  may  be  omitted. 

Note  L  -  Existence  of  sub- channel  indication  (Octet  5a-)  is  implicitly  indicated  by 
"Length  of  channel  identifier"  in  Octet  2. 

FIGURE  4-15/Q.930 

Ghannol  identification  information  element 


Extension  bit  (Octet  3,  3a,  3b,  4,  5a) 


0  :  description  is  extended  through  the  next  octet 
1  :  last  octet  of  the  description 

Interface  identifier  present  (Octer  3) 

0  s  Interface  implicitly  identified  (Note) 

Note  -  The  interface  which  includes  the  D- channel  carrying  this  information 
element  is  indicated. 

1  :  Interface  explicitly  identified  (in  Octer  3b) 

Interface  type  (Octet  3)  . 

0  :  basic  interface 
1  :  other  interface  (Note) 

Note  -  Interface  type  should  be  identified  by  the  interface  identifier. 
Preferred/Exclualve  (Octet  3) 

0  :  indicated  channel  is  preferred 

1  :  exclusive;  only  the  indicated  channel  is  acceptable 

D- channel  indicator  (Octet  3) 

0  s  no  D- channel 
1  :  D- channel  is  indicated 

Information  channel  selection  (Octet  3) 


Basic  interface 

Other  interface 

0  0  s 

No  channel 

No  channel 

0  1  s 

B1  channel 

As  indicated  below 

1  0  : 

B2  channel 

Reserved 

1  1  : 

Any  channel 

Any  channel 

Symmetry  (Octet  3a) 

0  0  :  duplex 
0  1  s  reserved 

1  0  :  simplex  outgoing  (from  user  to  network) 

1  1  :  simplex  incoming  (from  network  to  user) 

Note  -  If  octet  3a  is  omitted,  the  symmetry  is  assumed  to  be  duplex. 
Interface  identifier  (Octet  3b) 

Binary  code  assigned  to  the  interface  at  subscription  time. 

Note  -  When  the  interface  is  implicitly  identified,  octet  3b  is  omitted. 
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#/Map  (Octet  4,  5a) 

0  :  (sub-)  channel  is  indicated  by  the  number  (#) 

1  :  (sub-)  channel  is  indicated  by  the  slot  map  (Map) 

Note  -  If  map  element  type  is  8  kbit/s,  then  only  "1"  is  allowed. 

(Sub-)  channel  type /Map  (sub-)  element  type  (Octet  4,  5a) 

0001:  8  kbit/s  sub-channel 
0011:  B-channel 
0110:  HO- channel 
1000:  Hl-channel 

Note  -  All  other  values  are  reserved  for  further  study. 

(Sub-)  Channel  (Octet  5,  5b) 

Binary  number  assigned  to  the  channel. 

Note  1  -  Bit  8  is  reserved  for  extension. 

Note  2  -  Either  "Channel#"  or  "Slot  map"  is  used  exclusively,  depending  on 
the  '#/Map"  information. 

(Sub-)  Slot  map  (Octet  5,  5b) 

Bit  position(s)  in  slot  map  corresponding  to  time  slot(s)  used  by  the  (sub-) 
channel  is  set  to  1.  Some  examples  are  listed  below. 


Note  -  Length  of  the  slot-map  is  decided  by  combination  of  unit  on  which  the  slot  map 
is  mapped  and  map  element. 

Case  1  :  Primary  rate  interface,  map  element  =  B-channel 


1.5  M 

I  2  M 


Case  2  :  B-channel,  map  element  =  8  kbit/s  sub- channel 
87654321 


0/  0 ,  0 ,  0 .  0.  0 ,  0 ,  0 , 
'1  'l  '1  '1  'l  '1  'l  'l 
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Channel  identification 
1  110 
information  element  identifier 

0  0  0  1 
Length 


1  I  0  • 


Ext  Int  id ,  Int  type  j  Spare ' 


D-chi  Info  chan 
id  1  selection 


1 

1  ' 
Ext  1 

0 

0 

0  0  0  1 
(Interface#  3) 

1 

i ; 

Ext  , 

0  0 
(CCITT  St) 

1  ■ 

;  °  • 

■  W)' 

_ 1 _ L 

0  0  1 
(B-channel) 

1 

1  * 
Ext ; 

0 

0 

0  110 
(Channel  #12) 

0 

-  Other  interface 

-  #■  3  interface 
(e.g.  Primary- 

rate) 

-  16  kbit/s  sub¬ 
channel  in 


channel 

Dreferred 


(CCITT  St)  i  (Map)'  (8  kbit/s  slot  map  element) 


1  0  0  0  0  0  0 
(16  kbit/s  sub-channel) 


% 


.Vv 
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4.5*11  Compatibility 

The  purpose  of  the  compatibility  information  element  is  to  provide  a 
means  which,  in  association  with  the  bearer  service  information  element,  may  be  used 
by  the  network  or  the  remote  user  in  compatibility  checking.  The  use  and  the  detailed 
coding  of  this  Information  element  is  for  further  study. 

The  compatibility  information  element  is  coded  as  shown  in  Figure  4-16/Q.930. 
The  compatibility  information  element  may  be  repeated  in  a  message  to  convey  information 
related  to  more  than  one  CCITT  Recommendation.  The  network  will  assume  that  only  a 
Recommendation  1.200  bearer  service  is  to  be  provided  when  the  compatibility  information 
element  is  absent. 

Note  -  When  an  ISDN  provides  bearer  services,  this  information  is  not  interpreted  by 
the  network,  but  rather  is  carried  transparently  and  delivered  to  the  remote  user (a) . 

If  explicitly  requested  by  a  user  (on  a  per  call  basis  or  at  subscription  time),  a 
network  which  provides  some  capabilities  to  realize  telecommunication  services  may 
interpret  this  information  to  provide  a  particular  service. 


■OK- 


'mam. 


’«  •  **  k  *  •  l 

“vVj 

\«\-V 

„  ■  i « 


6 


5 


0 

Compatibility 

11  1110 
information  element  identifier 

0 

Length  of  compatibility  information 

0/1 

Ext 

Coding 

standard 

Profile 

Optional  detailed  description,  according  to  the 
Recommendation  specified  in  the  profile 
(for  further  study) 


Octet  1 


2 

3 

4 

etc. 


Extension  bit  (Octet  3) 

0  :  description  is  extended  through  the  next  octet 
1  :  last  octet  of  the  description 

Coding  standard  (Octet  3) 

0  0  :  CCITT  standard 

0  1  :  reserved  for  other  international  standards 
1  0  :  national  standard 

1  1  s  standard  specific  to  the  network  present  on  the  network  side  of  the 
interface . 

Profile  (Octet  3) 

5  4  3  2  1 

00001  Recommendation  X.25 

Examples  of  other  candidates  which  may  be  coded  as  CCITT  standard  are  : 

-  Recommendations  S£l,  62  (Teletex) 

-  Recommendation  T.a,  b  (Facsimile) 

-  Recommendation  S. 100  (Videotex). 

Hote  -  See  bearer-service  information  element  for  description  of  coding  laws,  e. 
telephony. 


g.  for 
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4.5.13  Connected  address 

The  purpose  of  the  connected  address  information  element  is  to  indicate 
which  address  is  connected  to  a  call.  The  connected  address (es)  may  be  different 
from  the  origination  or  destination  address(es)  because  of  changes  (e.g.  call 
redirection,  transfer)  during  the  lifetime  of  the  call. 

The  connected  address  information  element  is  coded  at  shown  in 
Figure  4-18/Q.930.  The  connected  address  may  be  repeated  in  a  message,  e.g.  for 
a  multipoint  call. 


8 

7  6  5 

4  3  2 

1 

0 

Connected  address 

0  0  0  1  1  0 
information  element  identifier 

0 

Octet  1 

Length  of  connected  address  information 

2 

Even/ odd 

Reserved 
(See  Note  2) 

Type  of  address 

3 

= 

Address 

digits 

0  0  0 
(fill) 

0 

4  etc. 

Mote  -  This  figure  is  drawn  assuming  an  odd  number  of  address  digits.  Within  each 
octet,  the  address  digit  in  bits  5-8  are  considered  to  precede  the  digit  in 
bits  1-4-  The  address  digits  in  octet  4  precede  the  digits  in  octet  5,  etc.  The 
address  digit  to  be  dialled  first  is  denominated  digit  1,  etc.  In  case  of  an  odd 
number  of  address  digits  bits  1  to  4  of  the  last  octet  shall  be  set  to  zero. 


FIGURE  4-18 ( 1/2 )/Q. 930 
Connected  address  information  element 


ibaddress  conveyed  together 
in  element  is  for  further  s' 
a  separate  specific  addresi 
is  information  element  conn 


331, 


address 

digit 

value 

0 


Reserved 
(see  Note  2) 


Type  of  address 


VV 


U;. 


•w  mb 
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4-5.17  Keypad  echo 

The  purpose  of  the  keypad  echo  information  element  is  to  convey  IA5  information 
echoed  to  the  user  by  the  network. 

The  keypad-echo  information  element  is  coded  as  shown  in  Figure  4-22/Q.930. 


Keypad  echo 

1  10  0  0 
information  element  identifier 


0  Octet  1 


Length  of  keypad  echo  information 

- 

IAS  information 

Keypad  echo  information  element 


4-5.18  More  data 

The  more  data  information  element  is  sent  by  the  user  to  the  network  in  a 
USER  INFO  message,  and  delivered  by  the  network  to  the  destination  user(s)  in  the 
corresponding  USER  INFO  message. 

The  use  of  the  more  data  information  element  is  not  supervised  by  the  network 
The  more  data  information  element  is  coded  as  shown  in  Figure  4-23/Q.930. 


More  data 

10  0  0 
information  element  identifier 


More  data  information  element 


Octet  1 
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4*5.19  Network-specific  facilities 

The  purpose  of  the  network-specific  facilities  information  element  is  to 
indicate  which  network  facilities  are  being  invoked  at  the  specified  network. 

The  network-specific  facilities  information  element  is  coded  as  shown  in 
Figure  4-24/Q.930. 


7  6  5  4  3  2  1 


| 

l  Network-specific  facilities 

ojoi  0  0  0  0  0 

I  information  .element  identifier 


Length  of  network-specific  facilities 
_ information'  element _ 

Length  of  network  identification 


Even-odd 

Nature  of  network 

Type  of  network 

0  0  0 

0 

identification  plan 

Spare 

Identification 

Network  identification  digits 

0  0  0  0  = 
rma  ■S  1 


Network-specific  facility  specification 


Octet 


1 

2 

3 


4* 


4a* 

5  etc. 


Soto  -  This  figure  is  drawn  assuming  an  odd  number  of  network  identification  digits. 
Within  each  octet,  the  network  identification  digit  in  bit3  5-8  are  considered  to 
precede  the  digit  in  bits  1-4.  The  network  identification  digits  in  octet  4  precede 
the  digits  in  octet  5,  etc.  In  case  of  an  odd  number  of  digits  bits  1  to  4  of  the 
last  octet  shall  be  set  to  zero. 

* 


May  be  omitted. 
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Length  of  network  Identification  (Octet  3)  : 

This  field  contains  the  length,  in  octets,  of  the  network  identification 
found  in  octets  4,  4a  etc.  If  the  value  is  "0000  0000",  then  the  local  serving 
network  is  assumed. 

Even-odd  (Octet  4.  bit  8)  : 

0  =  even  number  of  network  identification  digits. 

1  =  odd  number  of  network  identification  digits. 

Type  of  network  identification  (Octet  4)  : 

321  meaning 

000  unknown 

010  national  network  number. 

Reserved  (Octet  4)  : 

Octet  4,  bits  5-7  are  reserved  for  possible  use  as  a  network  numbering 
plan  indication.  The  value  "0000"  is  reserved  to  indicate  "unknown". 

Network  identification  digits  (Octets 


These  digits  are  organized  and  encoded  as  shown  for  address  digits 
(Octets  4,  etc.)  in  Figure  4-18/0.930. 

Network-specific  facilities  (Octet 


This  field  is  encoded  according  to  the  rules  specified  by  the  identified 


network. 
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4.5.20  Origination  address 

The  purpose  of  the  origination  address  information  element  is  to  identify 
the  origin  of  a  call. 

The  origination  address  information  element  is  coded  as  shown  in 
Figure  4-25/Q.930. 


0  l  1 

i 


Origination  address 
10  11 
information  element  identifier 


Octet  1 


Length  of  origination  address  information 

Even-odd  ,  Type  of  address 

_ |  (see  Figure. 4-  18/Q.930,Note  2)|  _ 

Address  digits 

0  0  0  0 
(fill) 


Note  -  The  contents  of  this  information  element  are  coded  as  shown  in 
Figure  4-18/Q.930. 


ation  address  Information  element 


4.5.21  Redirecting  address 


The  purpose  of  the  redirecting  address  Information  element  is  to  identify  a 
point  at  which  call  redlrection/diversion/ transfer  was  invoked. 

The  redirecting  address  information  element  is  coded  as  shown  in 
Figure  4-26/Q.930.  The  redirecting  address  information  element  may  be  repeated  in 
a  message  in  case  of  multiple  redirections. 

Note  -  The  distinction  between  call  redirection,  call  diversion  and  transfer,  if  any, 
is  for  further  study. 
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4.5-22  Signal 

The  purpose  of  the  signal  information  element  is  to  convey  indications 
causing  a  stimulus  mode  terminal  to  generate  tones  and  alerting  signals. 

The  signal  information  element  is  coded  as  shown  in  Figure  4-27/Q.930. 

The  signal  information  element  may  be  repeated  in  a  message  to  convey 
multiple  stimuli. 


Signal 

0  1  10  1 

information  element  identifier 

0  0  0  0  0 
Length  of  signal  Information  eleme 

Signal  value 


Octet  1 


il  value 

(Octet  3) 

0  0  0  0 

0  0  0  0 

dial  tone  on 

0  0  0  0 

0  0  0  1 

ring  back  tone  on 

0  0  0  0 

0  0  10 

intercept  tone  on 

0  0  0  0 

0  0  11 

network  congestion  tone  on 

0  0  0  0 

0  10  0 

busy  tone  on 

0  0  0  0 

0  10  1 

confirm  tone  on 

0  0  0  0 

Olio 

answer  tone  on 

0  0  0  0 

0  111 

call  waiting  tone  on 

0  0  0  0 

10  0  0 

off -hook  warning  tone  on 

0  0  11 

1111 

tones  off 

0  10  0 

0  0  0  0 

alerting  on  -  pattern  0 

0  10  0 

0  0  0  1 

alerting  on  -  pattern  1 

0  10  0 

0  0  10 

alerting  on  -  pattern  2 

0  10  0 

0  0  11 

alerting  on  -  pattern  3 

0  10  0 

0  10  0 

alerting  on  -  pattern  4 

0  10  0 

0  10  1 

alerting  on  -  pattern  5 

0  10  0 

Olio 

alerting  on  -  pattern  6 

0  111 

alerting  on  -  pattern  7 

0  10  0 

1111 

alerting  off 

■ ./  ./  ^ 


<  I 

*jU 
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4*5.23  Swltchhook 

The  purpose  of  the  swltchhook  information  element  is  to  indicate  the  state 
of  the  stimulus  mode  terminal  swltchhook  to  the  network. 

The  swltchhook  information  element  is  coded  as  shown  in  Figure  4-28/Q.930. 


Swltchhook 

0  1  1  0  11  0 
information  element  identifier 

0  0  0  0  0  0  1 
Length  of  swltchhook  Information  element _ 

Switch¬ 
es  0  0  0  0  0  hook  value 


Octet  1 


Swltchhook  value  (Octet 

on-hook 
off -hook. 


*« 


.  -*L  ■  .  -•  -• 

V.V  V  V  V 


tf  /v.  ** 
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4.5.25  Transit  network  selection 

The  purpose  of  the  transit  network  selection  information  element  is  to 
identify  one  requested  transit  network.  The  transit  network  selection  information 
element  may  be  repeated  in  a  message  to  select  a  sequence  of  transit  networks 
through  which  a  call  must  pass. 

The  transit  network  selection  information  element  is  coded  as  shown 
in  Figure  4-30/Q.930. 


Transit  network  selection 
11  110  0 
information  element  identifier 

Length  of  transit  network  identification 


Octet  1 


Even-odd 

Nature  of  network 

Type  of  network 

0  0  0 

0 

identification  plan 

Spare 

identification 

m 

Network  identification  , 

0 

0  fill  0  0  1 

Kote  -  The  contents  of  this  information  element  are  coded  as  shown  in 
Figure  4-24/Q-930,  octets  4,  4a,  etc. 


Transit  network  selection  information  element 
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4.5.26 


User-user  Information 


The  purpose  of  the  user-user  information  element  is  to  convey  information 
between  ISDN  users.  This  information  is  not  interpreted  by  the  network,  but  rather 
is  carried  transparently  and  delivered  to  the  remote  user(s). 

The  user-user  information  element  is  coded  as  shown  in  Figure  4-31/Q.930. 
there  are  no  restrictions  on  the  content  of  the  user  information  field. 

In  SETUP ,  ALERTing,  CONNECT,  Disconnect,  DETach,  and  RELeaae  messages, 
the  user  information  field  contained  inside  this  information  element  has  a  network- 
dependent  ma-ri nriTm  size  of  32  or  12S  octets.  The  evolution  to  a  single  ma-rimim  value 
is  the  long-term  objective,  the  exact  maximum  value  is  the  subject  of  further  study. 

In  USER  INFO  messages  sent  in  association  with  a  circuit-mode  connection, 
the  user  information  field  contained  inside  this  information  element  has  a  mmri imm 
size  of  32  octets.  For  USER  INFO  messages  sent  in  a  temporary  or  permanent 
user-user  signalling  connection,  the  user  information  field  contained  inside  this 
information  element  has  a  maximum  size  equal  to  the  max-tmirm  size  of  messages  defined 
in  section  4  (excluding  USER  INFO). 


User-user  information 
1  1111 
information  element  identifier 

Length  of  user  information 


Octet  1 


User  information 


User-uaep  Information  element 
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The  call  states  referred  to  In  this  section  cover  the  states  perceived  by 
the  network,  states  perceived  by  the  user  and  states  which  are  common  to  both  user 
and  network.  Unless  specifically  qualified,  all  states  described  in  the  following 
text  should  be  understood  as  common  (see  §§  2.1.1  and  2.1.2  for  user  and  network  call 
states  respectively).  An  overview  diagram  of  call  states  is  given  in§§  2.1.3  and 
2.1.4. 

Provisional  detailed  specification  and  description  language  (SDL)  diagrams 
and  state  transition  tables  for  the  procedures  specified  in  this  section  are  contained 
in  figures  5- /Q. 930  through  5- /Q- 930.  Points  requiring  further  study  are  indicated  in 
both  the  text  of  this  section  and  these  SDL  diagrams. 


Circuit-switched  calls  &ro  controlled  by  a  sequence  of  messages  flowing 
across  the  user-network  interface.  This  section  describes  the  sequence. 

All  messages  in  this  Recommendation  may  contain  two  types  of  information 
element/  functional  and/or  stimulus.  Functional  information  elements  are  characterized 
as  requiring  a  degree  of  intelligent  processing  by  the  terminal  in  either  their 
generation  or  analysis.  Stimulus  information  elements,  on  the  other  hand,  are  either 
generated  as  a  result  of  single  event  at  the  user/terminal  interface  (e.g.  key 
depression)  or  contain  a  basic  instruction  from  the  network  (e.g.  display)  to  be 
executed  by  the  terminal. 

Functional  information  elements  will  alwaya  be  used  in  a  standardized  way. 
Stimulus  information  elements  mentioned  in  5  5  and  §  7.1  to  S  7.4  of  this  Recommenda¬ 
tion  will  also  be  standardized.  The  precise  meaning  and  application  of  additional 
stimulus  information  elements  (see  S  7.5)  is  for  further  study. 

As  a  general  principle,  all  the  messages  sent  by  the  network  to  the 
terminals  may  contain  a  "Display"  information  element  whose  contents  may  be  displayed 
by  the  terminal;  the  content  of  this  information  element  shall  be  network  dependent. 

In  addition  to  the  messages  exchanged  as  described  in  the  following  sections, 
INFORMATION  messages  for  call  control  may  be  sent  by  a  terminal  or  by  the  network  at 
any  time  of  the  call  (i.e.  after  the  terminal  has  issued  or  received  a  set-up  message 
and  before  it  has  sent  or  received  a  disconnect  message).  Unless  specified  in  the 
following  text,  the  INFORMATION  message  may  contain  both  stimulus  and  functional  info¬ 
rmation  elements.  The  stimulus  type  information  elements  "Kevoad"  and  "Disnlay"  shall 
contain  strings  of  IA5  characters  arranged  according  to  network  dependent  rules.  Other 
stimulus  information  elements  shall  not  be  subject  to  the  same  coding  restrictions. 

Note  -  "Keypad"  information  elements  shall  only  be  conveyed  in  the  direction  user  to 
network  since  their  contents  represent  the  depression  of  keypad  buttons  or  an 
equivalent  pre-programmed  key  at  the  user  interface.  "Display"  information  elements 
shall  generally  be  conveyed  in  the  direction  network  to  user  but  may  be  generated  by 
the  user  in  some  circumstances  (see  §  5.2). 


.'-V  .-.v  „*■  Y%’. 


establishment  at  the  originating  exchange 


Before  these  procedures  are  invoked,  a  reliable  data  link  connection  must 
be  established  between  the  user  (TE/NT2)  and  the  network.  The  data  link  services 
described  in  Q.920  (1.441)  are  assumed. 

5. 1.1.1  Call  request 


a)  General 

&  user  initiates  call  establishment  by  transferring  a  SETUP  message  across 
the  user  network  interface.  Following  the  transmission  of  the  SETUP  message,  the 
call  shall  be  considered  by  the  user  to  be  in  the  CALL  INITIATED  state.  The  message 
shall  always  contain  a  call  reference,  selected  according  to  the  procedures  given  in 
§  4*3;  where  the  terminal  has  a  single  B-channel  connection  per  layer  2  end  point 
capability  with  one  call  at  a  time,  a  dummy  call  reference  value  (i.e.  all  zero) 
shall  be  used.  At  least,  the  bearer  service  information  element  is  contained  in  the 
message  even  in  the  case  of  overlap  sending.  This  information  element  is  assumed  to 
be  an  exclusively  functional  information  element. 

Furthermore  the  SETUP  message  may  also  contain  all  or  part  of  the  call 
information  (i.e.  address  and  facility  requests)  necessary  for  call  establishment 
depending  on  whether  or  not  en-bloc  or  overlap  procedures  are  being  used  respectively 
(see  §  5.1.1  b)).  This  call  information  may  be  included  within  "keypad"  information 
elements  or  in  other  functional  information  elements  (e.g.  called  address,  CUG 

identity  . ) .  A  mixture  of  keypad  information  and  functional  information  for 

conveying  call  information  is  not  precluded.  However,  a  given  element  of  the  call 
information  (e.g.  addressing)  must  be  sent  in  a  unique  way  (i.e.  keypad  or  functional) 


If  en-bloc  sending  is  used,  the  SETUP  message  should  contain  all  the 
information  required  from  the  user  by  the  network  to  process  the  call.  The  network 
sends  a  CALL  SENT  message  to  the  user  to  acknowledge  the  SETUP  message  and  to  indicate 
that  the  call  is  being  processed.  The  CALL  SENT  message  contains  the  B-channel 
allocated  to  the  call  and  to  which  the  user  must  be  attached.  At  this  point,  the  call 
enters  the  CALL  SENT  state. 

If  overlap  sending  is  used,  the  SETUP  message  will  contain  only  part  of  the 
information  required  by  the  network  to  process  the  call.  On  receipt  of  such  a  SETUP 
message,  the  network  initializes  timer  T302  and  sends  a  SETUP  ACKNOWLEDGE  message  to 
the  user.  If  the  SETUP  did  not  contain  any  element  of  call  information,  the  network 
will  also  return  dial  tone,  if  appropriate,  based  on  an  analysis  of  the  bearer 
service  information  element. 

The  SETUP  ACKNOWLEDGE  message  contains  the  information  element  "signal  -  dial 
on";  when  received  by  a  user  this  information  element  may  initiate  a  local  indication 
that  dialling  can  start  (e.g.  by  an  audible  or  visual  indication).  The  SETUP 
ACKNOWLEDGE  message  also  contains  the  B-channel  to  be  used. 

If  following  the  receipt  of  an  en-bloc  SETUP  message  or  during  overlap  * 
sending,  the  network  determines  that  the  call  information  received  from  the  user  is 
invalid  (i.e.  invalid  facility  request  or  address),  then  the  network  shall  initiate 
clearing  by  sending  a  DISCONNECT  message  to  the  user  (see  §  5. 1.3. 2). 
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After  receiving  the  SETUP  ACKNOWLEDGE  message,  the  user  sends  the  remainder 
of  the  call  information  in  one  or  more  information  messages.  If  dial  tone  has  been 
returned,  it  will  be  terminated  by  the  network  on  receipt  of  the  first  INFORMATION 
message.  The  call  information  in  the  message  which  completes  the  information  sending 
may  contain  a  "sending  complete"  indication  i.e.  as  part  of  the  called  address.  The 
network  shall  re-initialize  timer  T302  on  the  receipt  of  every  INFORMATION  message  not 
containing  a  sending  complete  indication  and  optionally  generates  an  INFORMATION 
message  containing  a  keypad  information  element  (for  echo). 

Following  the  occurrence  of  one  of  the  conditions  described  below,  the 
network  shall  send  a  CALL  SENT  message  to  the  user  and  cancel  timer  T302  where 
appropriate  : 

i)  the  expiration  of  timer  T302  (the  value  of  T302  requires  further  study); 

ii)  the  receipt  by  the  network  of  a  sending  complete  indication; 

iii)  analysis  by  the  network  that  all  call  information  necessary  to  effect  call 
establishment  has  been  received. 

Note  -  With  regard  to  case  i) ,  an  alerting  or  connect  indication  can  be  received  from 
the  called  party  before  timer  T302  expires  and  in  such  cases  an  ALERTING  or  CONNECT 
message  shall  be  sent  to  the  calling  user.  No  CALL  SENT  message  shall  be  sent  and 
T302  shall  be  cancelled. 


In  the  SETUP  message,  the  user  will  indicate  one  of  the  following  : 

i)  a  preferred  channel  with  no  acceptable  alternative; 

ii)  a  preferred  channel,  any  alternative  i3  acceptable; 

iii)  any  channel  is  acceptable. 

If  no  indication  is  included  alternative  iii)  is  assumed. 

In  cases  i)  and  ii),  if  the  preferred  channel  is  available,  the  network 
reserves  it  for  the  call. 

In  case  ii) ,  if  the  network  cannot  grant  the  specified  channel,  it  reserves 
any  other  available  B- channel  associated  with  the  D- channel. 

In  case  iii),  the  network  reserves  any  available  B-channel  associated  with 
the  D-channel. 

The  reserved  B-channel  is  indicated  in  the  first  message  returned  by  the 
network  in  response  to  SETUP  (i.e.  SETUP  ACKNOWLEDGE  or  CALL  SENT).  This  message  may 
also  be  used  to  activate  the  B-channel  connection  in  the  user's  equipment. 

In  case  i),  if  the  specified  channel  is  not  available,  and  in  cases  ii)  and 
iii),  if  no  channel  is  available,  a  DISCONNECT  message,  indicating  this  condition,  is 
sent  by  the  network.  However,  if  the  network  provides  facilities  in  the  "no  channel 
available"  condition  (e.g.  delayed  call  establishment),  it  may  instead  return  a 
SETUP  ACKNOWLEDGE  or  CALL  SENT  message  as  appropriate. 
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When  the  "no  channel  available"  condition  is  indicated  in  the  SETUP 
ACKNOWLEDGE  or  CALL  SENT  message,  the  user  may  clear  the  call  or  initiate  alternative 
procedures  instead  of  clearing.  Alternate  procedures,  for  example,  to  request  delayed 
call  establishment  by  the  exchange  when  a  channel  becomes  available,  are  for  further 
study. 

A  network  timer  T301  is  initialized  when  the  SETUP  ACKNOWLEDGE  message  is 
sent  indicating  that  no  channel  is  available,  and  the  timer  T301  is  reset  when  the 
user  initiates  either  clearing  or  some  other  procedure  permitted  to  the  user.  If  the 
timer  expires,  the  network  initiates  clearing  by  sending  a  DISCONNECT  message  to  the 
user  (see  §  5. 1.3.2).  The  value  of  T301  is  for  further  study. 


5.1. 1.2  Ca}1  sent 

After  completion  of  channel  selection,  and  when  the  network  has  received 
stiff icient  call  information,  it  determines  whether  the  call  can  be  established  as 
requested.  If  access  to  any  services  and  facilities  requested  is  not  authorized  for 
the  user,  the  network  initiates  clearing  of  the  call  with  a  cause  indicated  in  the 
DISCONNECT  message  sent  to  the  user.  Alternative  procedures,  for  example,  indicating 
call  failure  without  initiating  clearing,  are  for  further  study. 

If  access  to  requested  services  and  facilities  is  authorized  but  not 
presently  available,  the  network  shall  Initiate  clearing  of  the  call  (Bee  §  5. 1.3 -2). 
However,  if  the  network  provides  call  queueing  facilities,  it  may  place  the  call  on  a 
queue  for  the  requested  service  or  facility.  The  D-channel  messages  and  in-band  tones/ 
announcement  to  be  returned  by  the  network  in  such  circumstances  and  the  network's 
subsequent  treatment  of  the  call  require  further  study. 

If  access  to  the  requested  service  and  facilities  is  authorized  and  available 
the  network  proceeds  with  call  establishment. 

If  the  user  corresponding  to  the  called  address  and  the  calling  user  are 
served  by  the  same  exchange,  procedures  given  in  5.1.2  are  initiated. 

If  the  user  corresponding  to  the  called  address  is  served  by  another 
exchange,  appropriate  inter-exchange  signalling  and  switching  procedures  are 
initiated. 


Upon  receiving  am  indication  that  user  alerting  has  been  initiated  at  the 
called  address,  the  network  transfers  an  ALERTING  message  across  the  user-network 
Interface  of  the  calling  address.  This  message  may  cause  initiation  of  a  user  equipment 
generated  alerting  indication.  At  this  time,  the  call  enters  the  CALL-DELIVERED  3tate. 

5. 1.1.4  Call  samasSsfl 


Upon  receiving  an  indication  that  the  call  has  been  accepted,  a  CONNECT 
message  is  sent  across  the  user-network  interface  to  the  calling  user. 

This  message  indicates  to  the  calling  user  that  a  connection  has  been 
established  through  the  network  and  stops  a  possible  local  Indication  of  alerting. 
At  this  time,  the  call  enters  the  ACTIVE  state. 
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On  receipt  of  the  CONNECT  message,  the  calling  user  may  optionally  generate 
a  CONNECT  ACKNOWLEDGE  message .  The  network  shall  not  take  any  action  on  receipt  of 
this  message  when  it  perceives  the  call  to  be  in  the  ACTIVE  state. 

5.1.1. 5  nail  re  lection 

Upon  receiving  an  indication  that  the  remote  user  (or  network)  is  unable  to 
accept  the  call,  the  network  will  initiate  clearing. 

5.1.2  Cfjl  establishment  at  the  destination  exchange 

This  procedure  assumes  that  a  reliable  data  link  connection  providing 
services  described  in  Q.920  (1.441)  may  not  exist  before  the  first  layer  3  message  (SETUP) 
is  transferred  across  the  interface.  However,  reliable  data  link  connections  must  be 
established  by  each  of  the  users  (terminals  and/or  NT2s)  at  the  interface  before  they 
respond  to  the  SETUP  message.  Permanent  data  link  connections  are  not  precluded, 
may  be  recommended  as  a  national  option.  The  call  reference  contained  in  all  messages 
exchanged  across  the  user-network  interface  shall  have  the  value  specified  in  the 
SETUP  message  delivered  by  the  network.  However,  when  a  user  has  only  a  single  B-channel 
connection  per  layer  2  endpoint  capability,  it  shall  use  a  dummy  value  (all  zero)  for 
the  call  reference  in  all  messages  except  the  first  response  to  the  SETUP  message. 

This  response,  being  an  ALERTING,  CONNECT  or  RELEASE  message  must  contain  the  terminal 
capabilities  information  element,  indicating  the  terminal  can  only  support  a  single 
B-channel  connection  per  layer  2  endpoint  capability. 

5.1. 2.1  Incoming  call 

The  network  will  indicate  the  arrival  of  a  call  at  the  user-network  interface 
by  transferring  a  SETUP  message  across  the  interface.  This  message  is  sent  if  the 
network  can  select  an  idle  B-channel.  If  the  network  provides  facilities  in  "no 
B-channel  condition"  (e.g.  call  waiting),  the  message  may  also  be  sent  when  no 
B-channel  is  idle.  The  possible  use  of  other  messages  for  this  purpose 
(e.g.  information)  is  for  further  study. 

The  SETUP  message  always  includes  the  following  Information  elements  : 

a)  Call  reference 

b)  Bearer  service  identification 

c)  Channel  identification 

In  addition,  the  SETUP  message  may  include,  as  required,  the  information 
elements  described  in  S  3.2.24  (e.g.  display,  compatibility,  signal  (alerting-on) ) . 

Since  a  multipoint  terminal  configuration  may  exist  at  the  user-network 
Interface,  this  message  must  be  sent  using  a  broadcast  capability  at  the  data  link 
layer.  In  this  case,  the  SETUP  message  should  contain  the  DDI  address  where  appropriate 
and  sub-address  if  provided.  However  if  the  network  has  knowledge  that  a  single¬ 
point  configuration  exists  at  the  interface,  a  point-to-point  link  may  be  used  to  carry 
the  SETUP  message.  After  sending  the  SETUP  message,  the  call  is  in  the  CALL-PBr  "'’NT 
state.  The  network  initializes  timer  T303. 


Note  -  In  the  case  of  overlap  sending  within  the  network,  the  DDI  or  sub-addr«33  mav 
also  be  conveyed  by  means  of  INFORMATION  messages  to  the  called  user  in  the  point-to- 
point  configuration. 
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5. 1.2. 2 


3-channel  negotiatlor 


interface  structure 


When  the  network  selects  an  idle  B-channel  for  a  call,  terminals  on  a  basic 
access  can  only  accept  the  call  on  the  channel  indicated  in  the  SETUP  message. 

Further  study  is  required  on  the  need  for  channel  negotiation  when  a  single  point 
configuration  exists  on  a  basic  access. 


In  point-to-point  primary  rate  interface  structures  (e.g.  PABX),  negotiation 
between  the  network  and  user  will  be  permitted  on  the  selection  of  the  B  channel(s) 
for  the  call.  Only  B-channels  which  are  controlled  by  the  same  D-channel  will  be 
used  in  the  negotiation  procedure.  The  negotiation  procedure  is  as  follows  s 

1)  if  the  call  can  be  accepted  using  the  B-channel(s)  indicated  in  the  SETUP 
message,  an  ALERTING  or  CONNECT  message  is  sent  to  the  network  indicating 
those  B-channel ( s ) ; 

2)  if  the  call  cannot  be  accepted  using  the  B-channel(s)  indicated  in  the 
SETUP  message,  a  SETUP  ACKNOWLEDGE  message  is  sent  to  the  network  indicating 
alternative  B-channel ( s ) ; 

3)  when  the  network  receives  a  SETUP  ACKNOWLEDGE  message,  it  responds  with  an 
INFORMATION  message  indicating  either  : 

a)  the  B-channel  Indicated  in  the  SETUP  ACKNOWLEDGE  message  (negotiation 
successfully  terminated); 

b)  a  second  alternative  B-channel; 

c)  the  same  B-channel  indicated  in  the  SETUP  message.  After  sending  this 
message,  the  network  re-inltializes  timer  T303; 

4)  the  user  response  in  case  3  a)  above  is  an  ALERTING  or  CONNECT  message; 

5)  in  cases  3  b)  and  3  c)  above,  if  the  call  can  be  accepted  on  the  B-channel 
selected  by  the  network,  an  ALERTING  or  CONNECT  message  indicating  that 
B-channel  is  sent; 

6)  in  cases  3  b)  and  3  c)  above,  if  the  call  cannot  be  accepted  on  the 
B-channel  selected  by  the  network,  a  RELEASE  message  is  sent  to  the  network 
and  the  procedure  of  §  5. 1.3.1  is  followed; 

7)  if  the  timer  T303  expires  after  re-initializing  and  the  network  has  not 
received  either  an  ALERTING,  CONNECT  or  RELEASE  message,  then  the  network 
initiates  clearing  using  the  procedure  in  §  5. 1.3. 2. 


Idle  userJs  equipment  which  satisfies  the  compatibility  requirements 
indicated  in  the  SETUP  message  responds  with  either  an  ALERTING,  CONNECT,  FACILITY 
(e.g.  for  call  forwarding,  hold....),  or  information  message. 

The  INFORMATION  message  contains  the  sane  request  as  the  FACILITY  message 
in  specifically  defined  information  elements,  or  KEIPAD  information  elements. 

Busy  user's  equipment  which  satisfies  the  compatibility  requirements 
indicated  in  the  SETUP  message  responds  with  a  RELEASE,  ALERTING,  (e.g.  for  call 
waiting)  and/or  FACILITY/INFORMATION  message. 

If  the  compatibility  requirements  indicated  in  the  SETUP  message  are  not 
satisfied  or  the  user  wishes  to  refuse  the  call,  a  RELEASE  message  may  be  sent  with 
the  cause  "call  rejected"  and  the  user  should  then  assume  the  call  to  be  in  a  NULL 
state . 

In  both  the  above  cases,  receipt  of  an  ALERTING  or  CONNECT  message  causes  a 
corresponding  ALERTING  or  CONNECT  message  to  be  sent  to  the  calling  user  and  timer 
T30 3  is  cancelled.  The  effect  of  the  FACILITY  message  on  timer  T303  is  for  further 
study.  Vhere  multiple  ALERTING  messages  are  received  in  a  multipoint  access  line, 
only  the  first  is  treated  in  this  way.  When  the  first  CONNECT  message  is  received,  the 
network  sends  a  RELEASE  message  to  the  remaining  responding  terminals.  In  all  the 
above  cases,  receipt  of  a  valid  FACILITY  or  INFORMATION  message  causes  calling  user 
treatment  appropriate  to  the  facility  requested.  Such  treatment  is  for  further  study. 

The  use  of  a  SETUP  message  when  no  B-ehannel  is  available  is  for  further 

study. 

b)  Primary  rate  Interface  structure 


User  equipment  (intelligent  NT2  type)  can  respond  to  the  SETUP  message  with 
a  SETUP  ACKNOWLEDGE,  ALERTING,  CONNECT,  FACILITY/INFORMATION  or  RELEASE  message. 
Receipt  by  the  network  of  an  ALERTING  or  CONNECT  message  causes  a  corresponding 
ALERTING  or  CONNECT  message  to  be  sent  to  the  calling  user,  and  timer  T303  is 
cancelled.  Some  types  of  user  equipment  may  respond  as  described  for  the  basic 
access  Interface. 

The  use  of  a  SETUP  message  when  no  B-channel  is  available  i3  for  further 

study. 

c)  Failure  procedures 

If  the  network  does  not  receive  any  response  to  the  SETUP  message  within  a 
time  interval  T303,  the  SETUP  message  is  retransmitted.  If  no  response  is  received 
during  a  further  period  T303,  from  the  message  retransmission,  the  network  initiates 
clearing  procedures.  The  value  of  T303  is  for  further  study.  The  clearing  cause  sent 
to  the  calling  user  is  "no  user  responding". 
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If  a  RELEASE  message  is  received  whilst  T303  is  running,  the  message  cause 
shall  be  retained  by  the  network  and  returned  in  a  DISCONNECT  message  to  the  calling 
user  if  T303  expires  (i.e.  if  no  valid  ALERTINC-/CONNECT  message  has  been  received  from 
the  user) . 


Further  study  is  required  regarding  the  action  to  be  taken  by  the  network 
when  multiple  EEL  messages  are  received  with  different  causes. 

5. 1.2. 4  Call  accent 

A  user  indicates  acceptance  of  an  incoming  call  by  transferring  a  CONNECT 
message  across  the  user-network  interface  towards  the  network.  If  an  ALERTING  message 
had  previously  been  sent  to  the  network,  the  CONNECT  message  may  contain  only  the  call 
reference.  The  CONNECT  message  may  also  contain  the  switchhook  information  element 
(Off -hook). 

If  a  call  can  be  accepted  using  the  B-channel  indicated  in  the  SETUP  message, 
and  no  user  alerting  is  required,  a  CONNECT  message  may  be  sent  without  a  previous 
ALERTING  message.  In  this  instance,  the  CONNECT  message  contains  the  call  reference 
and  B-channel  specified  in  the  SETUP  message. 

Note  -  Further  study  is  required  on  the  need  for  means  to  avoid  service  degradation 
or  speech  clipping  on  connections  involving  an  NT2. 

5.1. 2. 5  Active  indication 

On  receipt  of  a  CONNECT  message,  the  network  completes  the  circuit  switched 
path  to  the  selected  B-channel  and  sends  a  CONNECT  ACKNOWLEDGE  message  to  the  user 
which  accepted  the  call.  The  CONNECT  ACKNOWLEDGE  message  includes  the  call  reference 
and  B-channel  specification.  It  may  contain  the  signal  Information  element  (alerting- 
off ) .  The  network  also  Initiates  procedures  to  send  a  CONNECT  message  towards  the 
calling  user. 

The  CONNECT  ACKNOWLEDGE  message  indicates  completion  of  the  circuit  switched 
connection.  There  may  not  be  end-to-end  communications  until  the  CONNECT  indication  is 
received  at  the  calling  user.  At  this  point,  the  call  enters  the  ACTIVE  state  where 
it  remains  until  clearing  is  initiated  or  until  the  call  is  suspended. 
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In  addition  to  sending  the  CONNECT  ACKNOWLEDGE  message  to  the  terminal 
{elected  for  the  call,  the  network  sends  a  RELEASE  message  to  all  other  terminals  at 
the  interface  which  had  sent  an  ALERTING  or  CONNECT  message  in  response  to  a  SETUP 
message.  This  message  is  used  to  notify  these  terminals  that  the  call  is  no  longer 
offered  to  them.  Each  user  receiving  the  message  will  return  a  RELEASE  ACKNOWLEDGE 
message  and  then  consider  the  call  to  have  returned  to  a  NULL  state.  The  network 
shall  maintain  a  timer  T308  in  accordance  with  i  5*1.3,  and  shall  retransmit,  the 
RELEASE  message  if  necessary. 

5.1.3  Call  clearing 

5. 1.3.1  Clearing  by  the  user 

a)  At  any  time  the  user  may  initiate  clearing  by  transferring  across  the  user- 
network  Interface  a  DISCONNECT  message.  Following  the  receipt  of  a  DISCONNECT  message, 
the  network  shall  consider  the  call  to  be  in  the  DISCONNECT  REQUEST  state. 


If  the  network  immediately  clears  the  call,  the  B-channel  used  In  the  call 
Is  disconnected  and  a  RELEASE  message  shall  be  sent  to  the  user.  On  receipt  of  the 
RELEASE  message  the  user  shall  release  the  B-channel  end  the  call  reference  and  send 
In  response  a  RELEASE  ACKNOWLEDGE  message. 

Following  the  transmission  of  the  RELEASE  message,  the  network  shall  start 
timer  T308.  Following  the  receipt  of  a  RELEASE  ACKNOWLEDGE  message  from  the  user,  the 
network  shall  cancel  timers  T308  and  both  the  B-channel  and  the  call  reference  shall 
be  released  for  future  use.  If  a  RELEASE  ACKNOWLEDGE  message  is  not  received  before 
timer  T308  expires,  the  RELEASE  message  shall  be  retransmitted  and  timer  T308  shall  be 
reinitialized.  If  no  RELEASE  ACKNOWLEDGEMENT  is  received  from  the  user  before  timer 
T308  expires  a  second  time,  the  network  shall  release  both  the  B-channel  and  the  call 
reference  for  future  use. 

The  RELEASE  message  has  only  local  significance  and  does  not  imply  an 
acknowledgement  of  clearing  from  the  remote  user. 

b)  In  some  cases,  network  facilities  may  require  the  network  to  retain  the  call 
reference  for  subsequent  use  after  disconnecting  the  B-channel  used  for  a  call.  The 
network  shall  inform  the  user  of  this  condition  by  sending  a  DETACH  message  in  response 
to  the  DISCONNECT  message  received  from  the  user.  The  call  shall  then  be  considered  by 
the  network  to  be  in  a  DETACHED  state. 

After  the  network  has  completed  processing  associated  with  the  call,  it  shall 
send  a  RELEASE  message  with  appropriate  information  to  the  user,  and  the  procedures  in 
a)  above  are  followed. 

The  network  shall  respond  to  all  messages  received  from  the  user  whilst  the 
call  is  in  the  DETACHED  state  by  sending  a  DETACH  message. 

c)  In  other  cases,  the  B-channel  connection  may  be  retained  by  the  network 
after  if  receives  a  DISCONNECT  message  (e.g.  for  emergency  services).  The  network 
shall  inform  the  user  of  this  condition  by  sending  a  DELAYED  DISCONNECT  message  in 
response  to  the  DISCONNECT  message  received  from  the  user.  The  network  shall  respond 
to  all  messages  subsequently  received  from  the  user  by  sending  a  DELAYED  DISCONNECT 
message.  Sending  of  DELAYED  DISCONNECT  messages  will  not  change  the  state  of  the  call, 
which  will  remain  in  the  DISCONNECT  REQUEST  state. 

When  the  network  is  willing  to  complete  clearing,  it  shall  send  a  RELEASE 
message  to  the  user. 

If,  after  having  sent  a  DELAYED  DISCONNECT  message,  the  network  wishes  to 
disconnect  the  B-channel  whilst  retaining  the  call  reference,  it  shall  send  a  DETACH 
message  and  the  procedures  in  b)  above  will  apply. 

Possible  procedures  to  return  to  the  ACTIVE  state  from  the  DISCONNECT  REQUEST 
state,  such  as  the  recor .motion  of  a  call  which  was  held  (e.g.  for  emergency  services) 
in  the  DISCONNECT  REQUEST  state  by  a  DELAYED  DISCONNECT  message,  are  for  further  study. 
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5-1-3.2  Clearing  bv  the  network 

a)  The  network  initiates  clearing  by  transferring  a  DISCONNECT  message  across 
the  user-network  interface.  At  the  instant,  when  the  DISCONNECT  message  is  sent  by  the 
network,  the  B-channel  used  in  the  call  is  disconnected  but  not  yet  available  for 
further  calls. 

The  user  will  respond  by  sending  a  RELEASE  message  (except  in  case  b)  below). 
This  message  indicates  the  deactivation  of  this  particular  transaction  (by  user)  to  the 
network.  Receiving  this  message,  the  network  releases  the  B-channel  and  the  call 
reference  for  future  use  and  returns  a  RELEASE  ACKNOWLEDGE  message  to  the  user.  If  no 
RELEASE  message  is  received  from  the  user  in  a  time  interval  T305  from  the  transmission 
of  the  DISCONNECT  message,  the  network  shall  send  a  RELEASE  message  to  the  user.  The 
network  shall  start  timer  T308  and  continue  as  described  in  i  5. 1.3*1  a). 

In  some  networks,  in  band  tones  and  announcements  will  be  provided  a3  call 
progress  information  for  calls  in  which  the  bearer  service  identification  supplied,  as 
part  of  the  call  information  by  the  calling  user,  has  indicated  that  this  would  be 
appropriate.  When  the  network  decides  to  initiate  clearing  for  such  calls,  the 
appropriate  in  band  tone  shall  be  sent  for  a  period  T306  prior  to  the  transmission  by 
the  network  of  a  DISCONNECT  message.  If  a  DISCONNECT  message  is  received  from  the  user 
during  a  period  covered  by  T306,  the  network  shall  remove  the  tone  or  announcement 
from  the  B-channel  and  shall  send  RELEASE  message  to  the  user. 

b)  In  some  cases,  the  user  may  wish  to  invoke  facilities  which  may  delay  the 
release  of  the  call  reference  whilst  allowing  the  release  of  the  B-channel.  In  these 
conditions  the  user  will  respond  to  the  DISCONNECT  message  by  sending  a  DETACH  message. 
On  the  receipt  of  the  DETACH  message,  the  network  shall  consider  the  call  to  be  in  a 
DETACHED  state  and  cancel  timer  T305- 

The  network  responds  to  the  DETACH  message  by  either  : 

i)  actioning  the  requested  facilities  and  then  sending  a  RET, EASE  message  to  the 
user; 

ii)  sending  a  RELEASE  message  if  the  requested  facilities  are  not  provided  or 
access  to  the  requested  facilities  is  not  permitted  to  the  user. 

c)  In  some  cases  the  user  may  receive  from  the  network  a  RELEASE  message  without 
having  received  a  previous  DISCONNECT  message  (e.g.  if  the  DISCONNECT  message  was 
corrupted  by  undetected  transmission  errors) .  In  these  cases  the  user  shall  return  a 
RELEASE  ACKNOWLEDGE  message  to  the  network  and  consider  the  call  to  be  in  the  NULL 
state. 

5. 1*3*3  Clear  collision 

Clear  collision  occurs  when  the  user  and  the  network  simultaneously  transfer 
a  DISCONNECT  message  specifying  the  same  call.  Both  the  terminal  and  the  exchange  will 
regard  the  call  a3  having  entered  the  DISCONNECT  REQUEST  state.  The  procedures  in 
§  5. 1.3*1  will  then  apply. 
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a)  Whenever  a  message  is  received,  at  either  side  of  the  interface,  specifying 
a  call  which  is  considered  to  be  in  either  the  ACTIVE  state  or  any  of  the  states  of 
call  establishment,  suspension  or  clearing,  but  for  which  a  response  is  not  prescribed 
by  the  procedures  in  i  5.1  or  §  5.2,  a  STATUS  message  is  returned  indicating  the  call 
state  of  the  receiver.  Subsequent  actions  taken  upon  receipt  of  a  STATUS  message  are 
for  further  study  (see  Table....).  The  STATUS  message  and  its  contents  are  defined  in 
i  3.2.26. 

b)  Whenever  the  network  receives  any  message  except  SETUP,  RELEASE,  RELEASE 

ACKNOWLEDGE  or  DISCONNECT  specifying  a  call  reference  which  it  does  not  recognize  as 

relating  to  an  active  call  or  a  call  in  progress,  it  initiates  clearing  according  to 

the  procedure  in  §  5. 1.3*2,  specifying  the  call  reference  in  the  received  message. 

c)  Whenever  the  user  receives  any  message  except  SETUP,  RELEASE,  RELEASE 

ACKNOWLEDGE  or  DISCONNECT  specifying  a  call  reference  which  it  does  not  recognize  as 

relating  to  an  active  call  or  a  call  in  progress,  it  initiates  clearing  according  to 

the  procedure  in  §  5. 1.3.1,  specifying  the  call  reference  in  the  received  message. 

d)  If  the  network  or  user  receives  a  DISCONNECT  message  specifying  a  call 
reference  which  it  does  not  recognize  as  relating  to  an  active  call  or  a  call  in 
progress  it  sends  a  RELEASE  message,  specifying  the  call  reference  in  the  received 
message. 

e)  If  the  network  or  user  receives  a  RELEASE  message  specifying  a  call 
reference  which  it  does  not  recognize  as  relating  to  an  active  call  or  a  call  in 
progress,  a  RELEASE  ACKNOWLEDGE  is  returned,  specifying  the  call  reference  in  the 
received  message. 

f)  If  the  network  or  user  receives  a  RELEASE  ACKNOWLEDGE  message  specifying 

a  call  reference  which  it  does  not  recognize  as  relating  to  an  active  call  or  a  call 
in  progress,  no  action  should  be  taken. 

g)  If  layer  3  is  notified  by  the  data  link  layer  entity  that  the  underlying 
data  link  is  disconnected,  it  should  not  immediately  clear  the  calls  supported  by  that 
data  link  but  should  attempt  to  re-establish  a  data  link  connection.  Although  messages 
in  transit  during  the  layer  2  failure  may  be  lost  or  duplicated  during  recovery,  as 

an  objective,  calls  which  were  stable  should  not  be  lost  if  layer  2  can  be  reconnected 
within  some  brief  interval  (determined  by  timer  T309,  to  be  defined).  Also  as  an 
objective  the  layer  3  procedures  should  provide  as  robust  recovery  procedures  as 
possible  even  for  those  calls  with  lost  or  duplicated  messages.  The  specific 
procedures  to  be  invoked  when  there  is  a  layer  2  disconnection  are  for  further  study. 

5. 1.3. 5  General  rules  for  message  processing 

The  following  rules  are  listed  in  order  of  precedence  : 

a)  when  a  message  is  received  that  is  less  than  three  octets  long,  that 

message  shall  be  ignored} 


b)  when  a  message  is  received  with  an  OSI  network  layer  protocol  discriminator 
not  in  accordance  with  §  4.2,  that  message  shall  be  ignored. 
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5-1-4  Call  rearrangements 

The  elements  of  procedure  in  this  section  provide  for  physical  layer  and/or 
data  link  layer  rearrangements  after  a  call  has  entered  the  ACTIVE  state  as  defined  in 
§  2. 2. 1-5-  They  are  intended  for  application  to  the  basic  interface  structure;  their 
possible  use  for  primary  rate  interface  structures  is  for  further  study. 

The  activation  of  this  procedure  at  a  user-network  interface  may  correspond 
to  a  number  of  possible  events  such  as  the  following  : 

-  physical  disconnection  of  user  equipment  and  reconnection  at  a  different 
connection  point  in  the  same  user-installation  (e.g.  comprising  a  number 
of  logically  associated  basic  interface  structures); 

-  physical  replacement  of  one  user  equipment  by  another  at  the  same 
connection  point; 

-  the  human  user  moves  from  one  equipment  to  another; 

-  suspension  of  call  and  its  subsequent  reactivation  at  the  same  user 
equipment  and  connection  point. 

The  procedures  in  this  section  are  described  in  terms  of  functional 
messages  and  information  elements.  These  procedures  may  also  be  realized  by 
stimulus  information  elements  within  INFORMATION  messages,  see  i  7. 

If  the  procedures  for  call  suspension  in  this  section  are  not  followed 
prior  to  the  physical  disconnection  of  the  terminal  from  the  interface,  then  the 
integrity  of  the  call  cannot  be  guaranteed  by  the  network. 

The  present  text  may  not  completely  describe  the  procedures  applicable  to 
calls  other  than  a  point-to-point  call  between  two  users  (e.g.  a  conference  call). 

5. 1.4.1  Call  suspension 

The  procedure  is  initiated  by  the  user  by  sending  a  SUSPEND  message, 
containing  the  current  call  reference,  to  the  network.  The  user  may  optionally 
include  in  this  message  a  bit  sequence  (e.g.  IA5  characters)  to  be  known  as  the  call 
identity  for  subsequent  reconnection.  Where  no  call  identity  is  included  by  the  user, 
the  network  allocates  a  null-value. 

5. 1.4.2  Call  suanended  state 

Following  the  receipt  of  a  SUSPEND  message  a  SUSPEND  ACKNOWLEDGE  message 
shall  be  sent  from  the  network  to  the  user  initiating  the  action,  and  a  network 
timer  T307  shall  be  initiated.  (The  value  of  T307  is  for  further  study.) 
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At  this  time,  the  network  will  consider  the  call  reference  to  be 
released.  The  B-channel  involved  in  the  connection  will  be  reserved  until 
reconnection  of  the  call  (or  until  a  clearing  cause  occurs,  e.g.  expiry  of  timer 
T307).  A  STATUS  message  with  cause  "remote  user  suspended"  to  the  other  address(es) 
Involved  in  the  call  with  the  address  of  the  user  which  initiated  the  action. 

When  the  user  receives  the  SUSPEND  ACKNOWLEDGE  message,  it  may  disconnect 
the  underlying  data  link  connection,  if  the  terminal  has  to  be  physically  disconnected 
from  the  interface. 
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5. 1.4- 3  Call  suspend  error 

On  receipt  of  a  SUSPEND  message,  the  network  will  respond  by  sending  a 
SUSPEND  REJECT  message  if  the  information  contained  in  the  SUSPEND  message  is  not 
sufficient  to  avoid  ambiguities  on  subsequent  call  re-establishment.  This  will  apply, 
in  particular,  when  at  a  given  user-network  interface,  a  SUSPEND  message  is  received 
with  a  call  identity  sequence  already  in  use,  or  when  the  SUSPEND  message  does  not 
contain  any  call  identity  sequence  and  another  call  with  a  null-value  is  in  the 
SUSPENDED  state  at  that  interface. 

In  this  case  the  state  of  the  call  is  not  altered  within  the  network 
(i.e.  it  remains  in  the  ACTIVE  state). 

5.1. 4- 4  Call  re-establishment 

At  the  connection  end  where  suspension  was  initiated,  the  user  may  request 
re-establishment  of  a  call  after  physical  reconnection  of  a  terminal  by  sending  a 
RESUME  message  containing  the  call  identity  used  at  the  time  of  call  suspension.  The 
call  reference  included  in  the  RESUME  message  may  be  the  one  relating  to  the  suspended 
call  or  a  new  one  chosen  by  the  user.  S-channel  information  may  be  included  in  the 
RESUME  message,  but  the  "any  B-channel  available"  option  specified  in  !  5.1.1. i  c) 
shall  be  used. 

If  the  terminal  was  physically  disconnected  from  the  interface,  a  data  link 
connection  must  be  re-established  by  the  user  before  sending  the  RESUME  message. 

On  receipt  of  the  RESUME  message,  the  network  shall  re-establish  the  call 
in  the  ACTIVE  state,  provided  that  the  call  was  not  cleared  due  to  other  reasons. 

The  network  3hall  then  send  a  RESUME  ACKNOWLEDGE  message  to  the  user  and  it  shall 
cancel  timer  T307.  The  RESUME  ACKNOWLEDGE  will  specify  the  B-channel  allocated  to 
the  call  by  the  network  according  to  the  procedures  specified  in  5  5. 1.1.1  c). 

If  the  call  is  reconnected  at  the  same  interface  point  where  it  was 
suspended,  then  the  previously  reserved  B-channel  will  be  used.  Otherwise,  any 
channel  may  be  selected  by  the  network.  If  the  call  is  reconnected  at  a  different 
interface  point,  then  the  reserved  B-channel  will  be  released  by  the  network  at  the 
time  of  reconnection. 

The  network  will  also  send  a  STATUS  message  with  cause  "remote  user 
resumed"  to  the  other  address(es)  involved  in  the  call. 

No  memory  of  a  previously  received  call  identity  sequence  is  kept  by  the 
network  after  sending  the  RESUME  ACKNOWLEDGE  message. 

If  the  call  had  been  cleared  by  the  network,  the  network  shall  respond  to 
the  RESUME  message  by  initiating  call  clearing  in  accordance  with  S  5. 1.3*2. 
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If  a  received  RESUME  message  cannot  be  actioned  by  the  network  (e.g.  as 
a  result  of  the  B-channel  selection  procedure),  a  RESUME  REJECT  message  should  be 
returned  to  the  requesting  user.  The  state  of  the  call  is  not  altered  within  the 
network. 
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If  timer  T307  expires  before  a  valid  RESUME  message  is  received  from  the 
user,  the  network  shall  initiate  clearing  of  the  call-  Moreover,  if  the  associated 
data  link  connection  was  not  disconnected,  the  network  shall  initiate  clearing 
procedures  towards  the  concerned  user  as  described  in  §  5.1. 3-2. 

5.1*5  Call  collisions 

Call  collision  occurs  when  a  user's  request  to  establish  a  call  encounters 
an  attempt  by  the  network  to  establish  a  call  at  the  same  interface.  Such  a  situation 
could  occur  if  both  the  network  and  the  user  will  send  a  SETUP  message  at  approximately 
the  same  time.  If  the  user  can  support  simultaneous  calls  and  sufficient  B-channels 
are  available,  the  collision  is  resolved  by  the  channel  selection  procedures  in 
§§  5. 1.1.2  and  5. 1.2. 2. 

If  only  B-channel  is  available,  the  network  shall  give  an  incoming  call 
preference  over  a  call  request  received  from  the  user. 

If  only  one  B-channel  is  available,  the  user  shall  generally  give  preference 
to  the  network  for  call  establishment.  However,  some  terminal  adaptors  supporting 
existing  non-voice  terminals  (e.g.  X.21)  may  need  to  resolve  call  collision  by 
clearing  the  incoming  call  and  reattempting  the  outgoing  call  set-up  in  order  to 
satisfy  the  requirements  of  the  "R"  interface. 

5.1.6  Control  of  user  facilities 

5. 1.6.1  General 

Two  procedures  for  the  control  of  user  facilities  are  defined  as  follows  : 

i)  control  of  call  related  facilities,  in  connection  with  a  call  control 

procedure,  and;: 

ii)  registration/cancellation  of  facilities,  independently  from  call  control 

procedures  and  from  any  particular  call. 

The  application  of  such  procedures  to  the  various  user  facilities  is 
described  in  the  specification  of  the  procedure  relating  to  the  user  facilities 
themselves.  Detailed  application  of  these  procedures  to  specific  user  facilities  is 
for  further  study. 

User  facilities  may  be  controlled  using  either  functional  information 
elements  carried  by  FACILITY  messages  in  accordance  with  internationally  standardized 
procedures  or  by  stimulus  information  elements  conveyed  in  INFORMATION  messages  in 
accordance  with  network  depend jnt  procedures. 

5. 1.6. 2  Control  of  call  related  facilities 

Requests  for  call  related  facilities  may  be  included  in  call  control 
messages.  Additionally  the  following  messages  may  be  used  to  control  call  related 
facilities  :  FACILITY,  FACILITY  ACKNOWLEDGE  and  FACILITY  REJECT.  Facility  control 
may  also  be  performed  by  using  INFORMATION  messages  containing  KEYPAD,  DISPLAY  and 
other  stimulus  information  elements. 

The  FACILITY  message  or  the  INFORMATION  message  is  sent  by  a  user  (calling 
or  called)  to  initiate  the  procedure  to  request  the  concerned  facility.  It  may  also 
be  sent  by  the  network  to  the  remote  user  if  the  control  procedure  of  the  facility 
requires  this  user  to  be  involved. 
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If  the  control  procedure  only  involves  the  initiating-  user,  the  network 
responds  to  the  FACILITY  message  with  either  a  FACILITY  ACKNOWLEDGE  or  FACILITY 
REJECT  message,  to  respectively  indicate  completion  or  rejection  of  the  procedure. 

If  the  facility  is  activated  by  using  an  INFORMATION  message,  the  network 
responds  with  an  INFORMATION  message  containing  DISPLAY  information. 

If  the  control  procedure  involves  the  remote  user,  this  user  responds  to 
the  FACILITY  message  with  either  a  FACILITY  ACKNOWLEDGE  or  FACILITY  REJECT  message. 

Alternatively  where  the  network  informs  the  remote  user  of  the  facility 
via  an  INFORMATION  message  that  user  shall  respond  with  an  INFORMATION  message 
containing  Keypad  information  elements. 

The  decision  to  use  functional  o” -stimulus  signalling  shall  be  taken 
locally  by  the  network  on  the  basis  of  user  characteristics  determined  by  the 
network  at  call  establishment  or  when  the  user  resumes  after  call  suspension. 

Following  the  receipt  of  such  message  from  the  remote  user,  the  network 
will  send  the  appropriate  message  to  the  initiating  user. 

The  above  indicating  messages  may  be  sent  in  the  active  state  of  the  call. 
Sending  of  a  message  does  not  in  it3elf  change  the  state  of  the  call;  however  this 
state  may  be  changed  as  a  result  of  the  facility  invoked. 

All  the  above  indicated  messages  contain  the  call  reference  appropriate 
to  the  call. 

5. 1.6. 3  Registration  and  cancellation  of  facilities 

The  following  messages  are  used  to  control  registration  and  cancellation 
of  user  facilities  J  FACILITY  REGISER,  REGISTER  ACKNOWLEDGE,  REGISTER  REJECT, 

FACILITY  CANCEL,  CANCEL  ACKNOWLEDGE,  CANCEL  REJECT. 

Facility  registration  and  cancellation  may  also  be  controlled  by  using 
stimulus  information  elements  (e.g.  Keypad)  within  INFORMATION  messages.  In  this  case, 
the  network  may  respond  using  DISPLAY  and/or  other  stimulus  information  elements 
conveyed  in  INFORMATION  messages. 

A  FACILITY  REGISTER  or  CANCEL  message  is  sent  by  a  user  to  initiate  a 
registration  or  cancellation  procedure  of  a  user  facility.  It  may  also  be  sent  by 
the  network  to  a  remote  user  is  the  control  procedure  of  the  facility  requires  this 
user  to  be  Involved. 

If  the  control  procedure  only  involves  the  initiating  user,  the  network 
responds  to  such  a  message  with  the  appropriate  ACKNOWLEDGE  or  REJECT  message  to 
indicate  completion  or  rejection  of  the  procedure. 

If  the  facility  requested  involves  the  agreement  of  a  remote  user,  this 
user  responds  to  the  message  with  the  appropriate  ACKNOWLEDGE  or  REJECT  message. 

The  network  transfers  the  message  to  the  initiating  user. 


•  V 
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The  above  indicated  messages  do  not  relate  to  a  call,  however  they  contain 
a  call  reference ,  which  is  the  same  in  the  REGISTER  or  CANCEL  and  ACKNOWLEDGE  or  REJECT 
messages  of  the  same  procedure.  The  REGISTER  and  CANCEL  messages  may  contain  the 
address  of  the  user  to  which  they  are  destined. 

5-1.7  Charging  indication 

5. 1.7.1  General 

Charging  indication  is  a  feature  allowing  a  user  to  be  informed  about  the 
charging  of  a  call.  It  is  for  further  study  if  it  is  to  be  provided  as  a  standard 
service  feature  or  as  a  user  facility  assigned  to  the  user  for  an  agreed  contractual 
period. 

5. 1.7. 2  Procedures 

Charging  indication  information  may  be  sent  by  the  network  to  the  appropriate 
user  (calling  or  called)  on  the  following  occasions  : 

i)  at  the  beginning  of  the  call,  to  indicate  the  charging  rate  plus,  when 
applicable,  charging  units  on  answer; 

ii)  during  the  call,  to  indicate  a  change  in  the  charging  rate; 

Hi)  during  the  call,  to  indicate  that  N  (value  for  further  study)  charging 
units  have  been  charged; 

iv)  at  the  end  of  the  call,  to  indicate  the  overall  charge. 

Note  -  It  is  for  further  study  how  items  i)-iv)  apply,  e.g.  if  they  have  to  be 
considered  as  separate  features  or  if  they  have  to  be  combined  as  part  of  the  same 
feature . 

Charging  indication  information  may  be  sent  to  the  calling  user  in  any  of 
the  following  messages  :  SETUP  ACKNOWLEDGE,  ALERTING,  CONNECT,  DISCONNECT,  RELEASE  and 
INFORMATION.  To  the  called  user,  it  may  be  sent  in  the  following  messages  :  SETUP, 
CONNECT  ACKNOWLEDGE  and  INDICATION,  DISCONNECT  and  RELEASE.  The  INFORMATION  message 
shall  be  used  during  the  ACTIVE  state  of  the  call  and  no  charging  indication 
information  shall  be  sent  when  the  call  is  in  the  SUSPENDED  state. 


The  closed  user  group  (CUG)  facility  is  assigned  to  a  user  for  an  agreed 
contractual  period.  Principles  and  procedures  to  be  used  are  in  accordance  with 
Recommendations  1.320,  Q.764  and  Z.87. 

The  SETUP  message  format  allows  the  inclusion  of  a  CUG  facility  request 
by  a  calling  user. 

Incoming  calls  associated  with  a  closed  user  group  shall  include  a  CUG 
facility  request  in  the  SETUP  message  delivered  to  the  called  user. 
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In  both  cases  the  facility  request  may  contain  an  index  referring  to  the 


particular  CUG  to  which  the  call  is  associated.  The  CUG  index  shall  only  have  local 
significance  at  each  user-network  interface.  If  no  CUG  facility  request  is  included 
by  the  calling  user  in  a  SET  UP  message,  then  the  preferential  CUG  for  that  customer 
will  be  assumed  by  the  network  (see  Recommendation  X . 37 ) . 

An  ISDN  user  may  be  registered  as  a  member  of  several  closed  user  groups, 
as  specified  in  relevant  CCITT  Recommendations. 

5-1.9  Calling  line  Identification 

Calling  line  identification  is  a  user  facility  assigned  to  a  user  for  an 
agreed  contractual  period.  It  applies  to  all  Incoming  calls  to  that  user.  Principles 
and  procedures  to  be  used  are  in  accordance  with  Recommendations  1.320,  Q.764  and  X.87. 

In  this  case,  the  SETUP  message  sent  to  the  called  user  includes  the  calling 
line  identity  provided  by  the  network,  encoded  as  the  origination  address  information 
element;  the  calling  line  identity  may  additionally  be  provided  in  the  "Display" 
information  element,  If  an  ALERTING  or  CONNECT  message  is  received  containing  an 
indication  that  the  called  terminal  cannot  handle  such  a  specific  information  element 
(stimulus  mode  terminal,  see  section  7),  then  the  network  will  send  a  second  time  the 
calling  line  identity  by  "Display"  information  in  an  INFORMATION  message. 

Some  networks  may  provide  calling  line  identity  within  the  CONNECT 

ACKNOWLEDGE  message. 

Note  -  Delivery  of  calling  line  identity  to  the  called  user  may  be  subject  to  agreement 
by  the  calling  user.  The  definition  of  a  possible  new  user  facility  to  allow  a  calling 
user  to  prevent  such  a  delivery  is  for  further  study. 

Called  line  Identification  is  a  user  facility  assigned  to  a  U3er  for  an 
agreed  contractual  period.  Ti  applies  to  all  outgoing  calls  from  that  user. 

Principles  and  procedures  to  be  used  are  in  accordance  with  Recommendations  1.320, 

Q.764  and  X.87. 

In  this  case,  the  CONNECT  message  sent  to  the  calling  user  includes  the 
called  line  Identity.  Depending  on  the  capabilities  of  the  calling  terminal  (i.e. 
if  it  is  a  stimulus  mode  terminal  or  not),  this  identity  will  be  3ent  as  "Display" 
information  or  as  a  specific  information  element. 

Note  -  Delivery  of  called  line  Identity  to  the  calling  user  may  be  subject  to  agreement 
by  the  called  user.  The  definition  of  a  possible  new  user  facility  to  allow  a  called 
user  to  prevent  such  a  delivery  is  for  further  study. 

5.1.11  Charing  method  selection 

The  charging  method  selection  facility  is  assigned  to  a  user  for  an  agreed 
contractual  period. 

The  SETUP  message  format  allows  the  inclusion  of  a  charging  method 
selection/indication  at  the  calling  user  interface  and  called  user  interface 
respectively . 
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This  facility  shall  allow  the  following  charging  methods  to  be  selected/ 
indicated  : 

a)  normal  charging  (in  this  case  normal  charging  shall  be  assumed  in  the 
absence  of  a  facility  request); 

b)  reverse  charging  (further  study  is  required  regarding  the  exact  method  of 
negotiating  this  facility  with  the  called  user) ; 

c)  other  charging  methods  (e.g.  credit  card)  require  further  study. 

5.1.12  Call  redirection 

The  call  redirection  facility  is  assigned  to  a  user  for  an  agreed 
contractual  period  and  causes  incoming  calls  to  be  redirected  to  an  address  previously 
specified  hy  the  called  user  at  the  time  of  facility  registration. 

The  user  may  register  a  request  for  call  redirection  by  using  the  procedures 
described  in  section  5.1.3,  i.e.  either  with  a  FACILITY  REGISTER  message  or  with 
stimulus  information  in  an  INFORMATION  message. 

The  principles  and  procedures  by  which  the  network  implments  this  facility 
shall  be  in  accordance  with  Recommendations  1.320,  Q.764  and  X.87. 

Additional  procedures  to  allow  e.g.  selective  redirection  of  calls  are  for 
further  study. 
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5.2.1 


General 


User-to-user  signalling  provides  a  means  of  communication  between  two 
customers  by  using  as  a  basis  the  layer  3  protocol  defined  in  section  5.1. 

User-to-user  signalling  is  used  to  exchange  information  between  two  users 
to  provide,  for  example,  additional  facilities  that  are  not  described  in  CCITT 
Recommendation  Q.930. 

The  exchange  of  user-to-user  signalling  is  limited  by  flow  control  procedures 
provided  by  the  network. 

Three  possibilities  of  user-to-user  signalling  are  provided  by  the  network 
to  the  users,  as  follows  : 

a)  user-to-user  signalling  in  association  with  a  circuit-switched  connection 
on  the  B-channel(s) ; 

b)  user-to-user  signalling  (not  associated  with  a  circuit-switched  connection) 
via  an  end-to-end  signalling  connection  which  is  dynamically  established; 

c)  user-to-user  signalling  (not  associated  with  a  circuit-switched  connection) 
via  an  end-to-end  signalling  connection  which  is  permanently  established. 

It  is  for  further  study  how  these  facilities  are  provided;  for  example,  as 
a  standard  service  feature  to  all  users,  as  a  user  facility  assigned  for  an  agreed 
contractual  period  or  on  a  per  call  basis.  Service  characteristics  including  tariff 
arrangements  are  for  further  study  by  the  relevant  Study  Groups. 

Note  -  Both  functional  and  stimulus  modes  of  conveying  user-to-user  information 
may  be  employed.  The  use  of  a  combination  of  modes  is  not  precluded. 

5.2.2  Gser-to-user  signalling  association  with  «  R- channel  connection 
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A  "User-user  information"  information  element  with  the  same  characteristics 
may  be  included  in  the  ALERTING  and/or  CONNECT  messages  transferred  across  the  user- 
network  interface  at  the  called  side  as  described  in  sections  5. 1.2. 2,  5.1. 2. 3  and 
5. 1.2. 4.  The  content  of  this  information  element  is  transferred  in  the  network  and 
delivered  in  the  corresponding  message(s)  transferred  across  the  user-network  interface 
at  the  calling  side  as  described  in  sections  5. 1.1. 5  and  5. 1.1. 6. 

Note  -  Where  user-to-user  information  is  conveyed  in  the  SETUP  message  via  "Keypad/ 
Display"  information  elements,  any  user-to-user  information  returned  in  the  ALERTING 
and/or  CONNECT  messages  shall  be  contained  in  "Display"  information  elements. 

If  a  multipoint  terminal  configuration  exists  at  the  user-network  interface 
at  the  called  side,  inclusion  of  the  "User-user  information"  information  element  in 
the  ALERTING  message  is  for  further  study;  moreover  if  in  such  a  case  more  than  one 
CONNECT  message  is  received,  the  content  of  the  "User-user  information"  information 
element  delivered  to  the  calling  user  is  the  one  in  the  message  received  from  the 
terminal  to  which  a  CONNECT  ACKNOWLEDGE  message  is  sent  as  described  in 
section  5. 1*2. 7. 

A  user  facility  request/indication  may  be  included  in  SETUP,  ALERTING  or 
CONNECT  messages  to  indicate  that  either  : 

i)  User-to-user  signalling  is  present  in  the  message  (Note  -  no  user-to-user 
signalling  is  allowed  in  the  ALERTING  message  for  point-to-multi point 
operation) 


ii)  the  originator  of  the  message  has  the  capability  to  receive  user-to-user 
signalling  information. 

The  precise  definition  of  the  facility  request  requires  further  study. 
However,  it  should  indicate  the  type  of  information  element  to  be  used  for  the 
conveyance  of  user-to-user  information  (i.e.  functional  or  stimulus). 

b)  Transfer  of  USER  INFO  messages 


Once  the  call  is  established,  both  the  involved  users  can  transfer 

information  between  themselves  by  transferring  USER  INTO  messages  across  the  user- _ 

network  interface.  The  network  provides  for  the  transfer  of  such  messages  from  the 
calling  to  the  called  side  and  vice-versa. 

The  USER  INFO  message  includes  as  information  elements  the  call  reference, 
the  user-user  information  as  defined  is  section  3.2.30  and  the  more  data  indication. 
The  more  data  indication  is  set  by  the  source  user  to  indicate  to  the  remote  user 
that  another  USER  INFO  message  will  follow,  containing  information  belonging  to  the 
same  block.  The  use  of  the  more  data  indication  is  not  supervised  by  the  network. 

If  the  user-to-user  signalling  facility  is  provided,  the  transfer  of  USER 
INFO  messages  across  the  calling  and  called  user-network  interfaces  may  be  performed 
in  the  following  states  (see  sections  2.2.1  and  2.2.2)  :  CALL- DELIVERED/CALL  RECEIVED 
and  ACTIVE.  No  more  than  two  messages  (provisional  value)  may  be  transferred  in  the 
CALL  DELIVERED/CALL  RECEIVED  states  in  each  direction;  transfer  of  message  in  such  a 
state  in  case  of  a  multipoint  terminal  configuration  is  for  further  study.  USER  INFO 
messages  received  from  the  user  in  any  other  state  of  the  call  are  discarded  by  the 
network  and  the  user  notified  with  a  STATUS  message  with  a  cause  "USER  INFO  local 
discard" . 
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In  any  case,  sending  of  USER  INFO  messages  does  not  change  the  state  of 


the  call. 


As  described  In  section  3*2.30,  USER  INFO  messages  may  contain  a  "User-user 
information"  information  element  or  a  "Display"  information  element.  The  choice  of 
information  element  should  be  made  according  to  the  user-to-user  facility  request  in 
the  SETUP  message. 

Note  -  Simple  terminals  may  transmit  user-to-user  information  via  "Keypad"  information 
elements  contained  in  INFORMATION  messages  at  any  phase  of  a  call  following  the 
generation  of  a  SETUP  message.  Such  user-to-user  information  shall  be  delivered  to 
the  remote  user  via  a  "Display"  information  element  contained  within  a  USER  INFO 
message.  The  ability  for  the  user  to  send  a  USER  INFO  message  with  the  "Display" 
information  element  (to  be  conveyed  transparently  by  the  network)  is  for  further  study. 

c)  Flow  control  of  USER  INFO  messages 

The  network  will  flow-control,  when  needed,  the  transfer  of  USER  INFO  messages 
from  a  user  by  means  of  a  CONGESTION  CONTROL  message  containing  a  "Congestion  level" 
information  element.  Two  indications  of  "Congestion  level"  are  specified  :  "receive 
not  ready"  and  "receive  ready" .  On  receipt  of  the  former,  the  user  should  suspend 
sending  USER  INFO  messages;  on  receipt  of  the  latter,  sending  may  recommence.  After 
having  sent  a  receive  not  ready  indication,  the  network  may  discard  USER  INFO  messages 
which  are  subsequently  received  and  the  user  notified  by  a  STATUS  message  with  a  cause 
"User  INFO  local  discard"  for  at  least  the  first  discarded  message. 

The  receipt  of  the  receive  ready  indication  by  the  user  shall  be 
interpreted  by  the  user  as  an  indication  that  no  more  than  "n"  USER  INFO  messages  may 
be  sent  before  another  receive  ready  indication  is  received  from  the  network.  The 
value  of  "n"  requires  further  study. 

Note  -  Where  user-to-user  information  has  been  conveyed  within  "Keypad"  or  "Display" 
information  elements,  CONGESTION  CONTROL  message  may  also  contain  "Display" 
information  elements.  The  character  sequences  contained  in  the  "Display"  information 
elements  shall  be  network  dependent. 

The  network  will  send  a  receive  not  ready  indication  whenever  a  USER  INFO 
message  is  locally  discarded.  The  possible  inclusion  of  additional  indications  in  the 
CONGESTION  CONTROL  message  to  signify  intermediate  congestion  levels  between  "receive 
not  ready",  and  "receive  ready"  is  for  further  study. 

d)  Call  clearing 

A  "user-user  information"  information  element  with  the  characteristics  above 
described  may  be  included  in  the  DISCONNECT,  DETACH  and  RELEASE  messages.  The 
information  contained  in  such  an  information  element  is  transferred  to  the  remote  user 
in  the  corresponding  clearing  message.  Such  a  transfer  is  only  performed  if  the 
information  is  received  at  the  local  exchange  of  the  remote  user  before  sending  a 
clearing  message  to  that  user;  otherwise,  the  information  is  discarded. 

Note  -  Application  of  flow-control  procedures  by  the  user  is  for  further  study. 
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User-to-user  signalling  via  a  tei 


■ling  connection 


a)  General  characteristics 


This  feature  allows  the  users  to  communicate  by  means  of  user-to-user 
signalling  without  setting  up  a  circuit-switched  connection.  A  temporary  signalling 
connection  is  setup  and  cleared  in  a  similar  way  to  the  control  of  a  circuit-switched 
connection,  as  detailed  in  the  following. 

b)  Call  establishment 

Procedures  for  call  establishment  are  as  described  in  sections  5.1.1  and 
5.1.2  with  the  following  modifications. 

On  call  request,  the  SETUP  message  sent  by  the  calling  user  will  indicate 
"1.451  user-to-user  signalling"  in  the  bearer.  Service  identification  information 
element,  thereby  indicating  to  the  network  that  the  establishment  of  a  B-channel 
connection  is  not  required.  Moreover  nor  B-channel  preference  is  Indicated,  as 
described  in  section  5. 1.1. 2.  Similar  rules  apply  to  the  SETUP  message  sent  at  the 
called  side.  Sending  of  call  information  is  always  performed  en-bloc. 

Procedures  as  described  in  i  5.2.2  apply  for  the  inclusion  of  the  "User-user 
information"  information  element  in  call  establishment  messages  and  for  the  handling 
of  ALERTING  and  CONNECT  messages. 

c)  Transfer  of  USER  INFO  messages 

The  procedures  described  in  section  5.2.2  b)  apply,  where  the  call  reference 
applies  to  the  signalling  connection. 

d)  Flow  control 

The  procedures  described  in  section  5.2.2  c)  apply. 

e)  Call  clearing 

The  procedures  for  clearing  the  signalling  connection  are  as  described  in 
sections  5.1.3  and  5.2.2  d). 

5.2.4  User-to-user  signalling  via  a  permanent  signalling  connection 

This  feature  allows  the  users  to  communicate  by  means  of  user-to-user 
signalling  without  setting  up  a  circuit-switched  connection;  moreover,  the 
cosBBunl cation  is  permanently  in  the  ACTIVE  state.  Thus,  the  only  messages  transferred 
by  the  users  across  the  user-network  interface  are  the  USER  INPO  messages. 

Procedures  for  transfer  of  USER  INTO  messages  are  as  discribed  in 
section  5.2.2  b).  The  value  of  the  call  reference  is  as  specified  in  section  5.2.3  b) 

Procedures  for  flow  control  are  as  specified  in  section  5.2.2. 

5.3  Procedures  for  packet  communications 

This  section  is  intended  to  explain  the  role  of  the  D- channel  signalling 

procedures  in  the  support  of  packet  communications  in  an  ISDN.  A  complete  description 
of  terminal  adaptor  (TA)  functions  necessary  for  X.25  terminals  support  can  be  found  i 
Recommendation  X. 31  (1.472)  together  with  a  description  of  ISDN-based  packet  handling 
functions . 
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According  to  the  scenarios  defined  in  Recommendation  X.31  (1.472),  packet 
communi cations  may  be  accessed,  using  either  : 

a)  the  maximum  integration  scenario.  In  this  case  a  packet-handling  function 
(PH)  is  included  within  an  ISDN.  In  this  case  any  channel  may  be  used  for 
access; 

b)  the  minimum  integration  scenario.  In  this  case  only  a  B-channel  is  used 
for  access . 

The  procedure  in  sections  5*3.2  and  5*3.3  apply  to  the  maximum  integration 

scenario. 


5.3*1  Packet  switching  service  via  B-channel 

In  this  context,  the  ISDN  provides  a  physical  64  kbit/s  semi-perminent  or 
switched  channel  between  the  appropriate  PH/PSPDN  port  and  the  user  terminal  (TE1/TA) 
at  the  customer  premises.  The  user  terminal  shall  communicate  with  the  PH/PSPDN  over 
the  B-channel  using  full  X.25  procedures  (layers  2  and  3). 

In  the  case  of  semi-permanent  access,  the  user  terminal  shall  be  dedicated 
to  the  corresponding  PH  function  or  ISDN  interface  port  at  the  PSPDN  (IP). 

In  the  case  of  switched  access,  the  user  terminal  shall  first  set  up,  via 
the  ISDN  signalling  procedure,  the  path  towards  the  PH/PSPDN  port  (layer  1  set  up) 
before  starting  X.25  layer  2  and  layer  3  functions. 


apply. 


For  calls  originated  by  the  PH/PSPDN,  the  same  considerations  as  above  shall 


5-3. 1.1  Elements  of  procedu 
5. 3. 1.1.1  Outgoing  call 


1)  Establishment  of  the  circuit-mode  connection  (B-channel)  to  PH/PSPDN 

a)  Leased  connection 

The  method  of  establishment  of  leased  circuits  is  for  further  study. 

b)  Switched  connection 

Switched  connections  to  a  PSPDN  or  PH  shall  be  established  using  the  D-channel 
si;-ialling  procedures  for  outgoing  call  establishment  described  in  section  5.1.1. 

2)  Packet-mode  operation 


Following  the  establishment  of  the  connection,  the  user  terminal  shall 
communicate  with  the  PSPDN  or  PH  using  full  X.25  procedures  (layers  2  and  3) • 

3)  Clearing  of  the  circuit-switched  connection  to  the  PH/PSPDN 


a)  Leased  connection 

The  method  of  clearing  of  leased  circuits  is  for  further  study. 


b)  Switched  connection 


The  clearing  of  the  switched  connection  shall  be  effected  by  using  the 
D-channel  signalling  procedures  for  call  termination  described  in  section  5.1.3.  Thus 
the  B-channel  may  be  cleared  at  any  time  by  the  user  though,  in  general,  it  will  be 
cleared  following  the  clearing  of  the  last  virtual  call  over  that  B-channel.  The 
circumstances  in  which  the  network  shall  clear  the  connection  require  further  study. 

5. 3*  1.1.2  Incoming  edlg 

1)  Establishment  of  the  circuit-switched  connection  (B-channel)  to  TA/TE1 

The  B-channel  to  the  called  user  shall  be  established  by  the  network  using 
the  D-channel  signalling  procedures  for  incasing  call  establishment  described  in 
section  5.1.2.  The  call  will  be  either  offered  to  all  packet-mode  user  equipment  at 
the  user  interface  or  to  a  single  user  equipment  identified  by  the  TEI  value  of  the 
TA/TE1  (see  section  5.2.3)  or  by  means  of  the  ISDN  sub-address. 

2)  Packet-mode  operation 

Following  the  establishment  of  the  connection,  the  PH/PSPDN  shall  use  1.25 
procedures  (layers  2  and  3)  to  communicate  over  the  B-channel  to  the  called  user. 

3)  Clearing  of  the  B-channel  connection 

See  section  5. 3. 1.1. 1.3. 

5. 3. 1.2  Overview  diagrams  of  signalling  flow 

Figures  5-1/0-930  and  5-2/Q.930  describe  the  signalling  message  flows  on 
the  D-channel  and  the  X.25  transmissions  on  the  B-channel  necessary  to  effect  X.25 
packet  communications  over  the  B-channel. 

Sote  -  These  figures  are  included  for  explanatory  purposes  and  do  not  show  all  X.25 
frames  which  may  be  sent  across  the  user-network  interface  within  the  B-channel  (e.g. 
layer  2  acknowledgements  of  I  frames  and  the  possible  use  of  the  restart  procedure). 

5-3-2  Packet  switching  service  via  the  D-oh*nn«»l 

The  D-channel  enables  ISDN  user  terminals  to  access  a  PH  function  within 
the  ISDN  by  establishing  a  data  link  connection  to  that  function  which  can  then  be 
used  to  support  packet  communication  according  to  X.25  layer  3  procedures.  The 
address  of  the  ISDN  interface  over  which  such  access  is  being  made  will  be  known 
either  directly  or  indirectly  by  the  PH  function.  The  specific  address  of  the 
terminal  making  this  access  shall  be  supplied  by  the  layer  2  service  of  the  D-channel 
access  link. 

The  layer  2  procedures  shall  be  in  accordance  with  Recommendation  Q.920 
(1.441).  The  D-channel  provides  a  semi -permanent  connection  for  packet  access  since 
all  layer  2  frames  containing  a  packet-mode  SAFI  will  be  routed  automatically  between 
the  user  and  PH  function. 
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The  PH  function  may  3 1ml laxly  effect  the  establishment  of  data  link 
connection  over  the  D-channel  of  an  ISDN  interface  to  a  user  equipment  capable  of 
operating  in  the  packet  mode  in  order  to  deliver  an  incoming  packet  call.  In  this 
case,  the  call  will  be  either  offered  to  all  packet-mode  user  equipment  at  the  user 
interface  or  to  a  single  user  equipment  specified  by  the  TEI  value  in  accordance  with 
the  channel  selection  procedures  described  in  section  5  -  3 • 3  - 

A  number  of  packet-mode  user  equipments  can  operate  simultaneously  over  the 
D- channel,  each  using  a  separate  layer  2  link  identified  by  an  appropriate  address  (see 
Re  commendation  Q.920  (1. 441 11  in  frames  transferred  between  the_usex-  ancLPH  -function* _ 

5.3. 2.1  Overview  diagrams  of  message  flows 

Figures  5-3/Q.930  and  5-4/Q.930  describe  the  message  flows  for  packet 
communi cations  over  the  D-channel. 

Note  in  section  5. 3.1.2  applies. 

5-3.3  Packet-switching  service  with  ghannal  selection 

The  choice  of  which  channel  to  use  for  the  delivery  of  a  new  incoming  packet 
call  shall  be  made  by  the  PH  according  to  certain  criteria  (see  Recommendation  X.31 
(1.472),  section  3.2.2).  In  the  most  general  case,  new  incoming  packet  calls  may  be 
indicated  to  the  ISDN  customer  via  the  point- to-multipoint  call  offering  procedures . 

The  call  offering  procedure  is  performed  using  the  layer  3  messages  and  procedures  of 
section  5.1.2  and  these  layer  3  messages  may  be  carried  in  data  link  layer  frames 
with  the  Service  Access  Point  Identifier  (SAPI)  indicating  either  packet  data  (p)  or 
signalling  (s)  information  (see  Recommendation  Q.920  (1.441)).  The  choice  of  which 
of  these  two  alternative  procedures  to  be  used  is  a  network  option,  e.g.,  which  may  be 
specified  at  subscription  time  or  may  be  dependent  on  the  channel  being  offered  for 
the  new  incoming  packet  call  in  the  call  offering  procedure.  The  operation  of  these 
two  alternative  procedures  is  as  follows  : 

a)  Networks  using  SAPI  =  "s"  at  data  link  layer 

In  this  case  the  call  offering  procedure  is  integrated  into  the  circuit- 
switched  call  control  procedures  with  the  channel  selection  being  accomplished  by  means 
of  the  channel  negotiation  procedures  if  offered  as  a  network  option  (see 
section  5. 1.2. 2).  However,  in  the  case  where  the  TA/TE1  requests  the  new  incoming 
packet  call  on  either  a  B-channel  already  established  for  packet-mode  calls  or  on  the 
D-channel,  the  network  will  terminate  the  layer  3  procedures  after  the  channel 
negotiation  phase  using  the  RELEASE  message. 

b)  Networks  using  SAPI  =  "pn  at  data  link  layer 

In  this  case,  the  call  offering  procedure  takes  the  form  of  an  enquiry/ 
response  interaction  at  layer  3  which  precedes  any  procedures  for  circuit  or  packet- 
switched  call  control.  The  call  offering  procedure  uses  identical  messages  to  the 
SET-DP,  SET-DP  ACE,  RELEASE  and  RELEASE  ACE  messages  described  in  section  5.  The 
channel  selection  function  is  performed  using  the  layer  3  channel  negotiation  procedures 
of  section  5. 1.2.2  if  offered  as,  a  network  option.  The  four  messages  of  the  call  offer¬ 
ing  procedure  are  conveyed  using  the  Unacknowledged  Information  Transfer  Service  at 
data  1 1 ek  layer.  If  the  TA  requests'  the  use  of  a  free  B-channel  lien  following  the 
call  offering  procedure,  the  network  shall  initiate  the  establishment  of  a  9-channel 
to  the  selected  TA/TE1  by  using  the  procedures  described  in  section  5.1.2.  In  this 
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case,  the  called  TA/TE1  shall  be  identified  by  means  of  the  TEI  value  of  the  TA/TE1 
which  is  returned  with  the  SET-UP  ACK  response  to  the  SET-UP  message  during  the  call 
offering  sequence.  Alternatively,  the  TA/TE1  may  be  identified  by  a  sub-address  in 
which  case  the  establishment  of  a  B-channel  to  the  selected  TA/TE1  may  be  achieved 
using  the  point-to-multipoint  incoming  circuit-switched  call  procedures.  If  the  TA/TE1 
requests  the  incoming  packet  call  on  either  a  B-channel  already  established  for 
packet-mode  calls  or  on  the  D-channel,  then  no  further  D-channel  signalling  (following 
the  call  offering  procedure)  is  required  before  the  X.25  procedures  begin. 

According  to  the  extent  of  addressing,  sub-addressing  and  bearer  service 
indication  information  provided  by  the  calling  terminal,  these  procedures  will  allow 
the  call  to  be  offered  to  a  subset  of  the  terminal  population  at  the  ISDN  address  or 
to  a  specific  interface  at  reference  points  S  or  T. 

Apart  from  this  general  approach  to  Incoming  call  offering,  in  some 
circumstances  and  optional  (for  a  period  for  which  the  facility  is  subscribed),  the 
service  characteristics  for  a  particular  ISDN  address  may  be  registered  at  the  PH  such 
that  the  network  may  choose  the  access  channel  for  a  particular  incoming  call  packet. 
Furthermore,  in  such  cases,  it  shall  also  be  possible  to  route  an  incoming  call  packet 
to  the  called  terminal  over  an  established  B-channel  connection  or  D-channel  link 
without  the  need  for  any  preceding  D-channel  signalling.  Also  some  networks  may  not 
provide  an  option  for  channel  negotiation.  In  this  manner  the  particular  approach  to 
incoming  call  routing  may  be  tailored  to  meet  the  particular  requirements  of  the 
network  and  the  user. 

Where  a  number  of  ISDN  lines  form  a  "Hunt  Group" ,  successive  incoming  packet 
calls  may  be  routed  on  different  lines  in  accordance  with  the  line  selection  algorithm 
associated  with  that  group.  Each  call  will  be  offered  on  the  chosen  line  using  either 
the  general  call  offering  procedure  or  specific  incoming  call  routing  as  appropriate. 

The  channel  selection  procedure  for  incoming  calls  is  independent  of  the  type 
of  channel  selected  at  the  calling  end.  In  this  respect,  any  combination  of  channel 
type  used  at  each  end  is  possible. 


5-6/Q.930. 


The  procedures  for  channel  selection  are  shown  in  Figures  5-5/Q-930  and 


Key  to  the  Figures  5-1/Q.930  through  5.6/Q.930 

D-channel  signalling  messages 

L  J  Layer  3 
C  -  CONNECT 

CA  -  CONNECT  ACKNOWLEDGE 
CC  -  CALL  CONNECTED 
D  -  DISCONNECT 
R  -  RELEASE 
IC  -  INCOMING  CALL 
S  -  SET-UP 

SA  -  SET-UP  ACKNOWLEDGE 

CS  -  CALL  SENT 

RA  -  RELEASE  ACKNOWLEDGE 
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level  3  messages 

Any  layer  3  message  proceeded  by  X.25  indicates  an  X.25  layer  3  packet 
e.g.  [_  X.25  CR_/  =  X.25  Call  Request  packet. 

CA  -  CALL  ACCEPTED 
CC  -  CALL  CONNECTED 
CLC  -  CLEAR  CONFIRMATION 
CLI  -  CLEAR  INDICATION 
CLR  -  CLEAR  REQUEST 
CR  -  CALL  REQUEST 
IC  -  INCOMING  CALL 


&  # 


er  2  frames 

()  -  Layer  2 
GTEI  -  Group  TEI 

A,B  -  X.25  layer  2  addresses  (includes  command  and  response) 

Layer  2  addresses  marked  (X,  p)  indicates  that  the  SAPI  element  of  the 
frame  address  is  coded  as  for  packet  type  information  as  described  in 
Recommendation  Q.920  (1.441).  Layer  2  addresses  marked  (X,  s)  refer  to 
signalling  type  information 

SABM  -  Set  Asynchronous  Balance  Mode  frame 
UA  -  Unnumbered  Acknowledgement  frame 

UI  -  Unnumbered  Information  frame  (i.e.  using  unacknowledged  information 
transfer  service  at  data  link  layer) 

I  -  Information  frame 
DISC  -  Disconnect  frame 
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operating  In  a  stimulus  mode 

This  section  describes  how  the  circuit-switched  call  control  procedures  of 
3  5  may  be  used  by  an  ISDN  terminal  operating  in  stimulus  mode  to  establish  a 

simple  call. 

For  explanatory  purposes,  stimulus  mode  terminals  have  been  classified  in 
this  section  into  the  following  types  : 

-  Type  1  terminals  for  which  each  layer  3  endpoint  has  a  unique  data  link 
layer  address  (i.e.  only  one  8-channel  may  be  connected  at  a  time  per  data 
link  layer  address). 

-  Type  2  terminals  for  which  multiple  layer  3  endpoints  may  be  associated  with 
a  single  data  link  layer  address  (i.e.  multiple  B-channels  may  be  connected 
per  data  link  address ) . 

Thus  the  procedures  of  §  5  may  be  simplified  for  Type  1  terminals  with 
respect  to  the  use  of  the  call  reference.  In  this  respect,  the  data  link  layer 
address  provides  a  unique  call  identity  and  Type  1  terminals  need  only  include  a  dummy 
call  reference  in  all  signalling  messages  other  than  in  the  first  response  to  a  SETUP 
message  (see  section  6.2).  Type  2  terminals  are  required  to  general  a  call  reference 
in  accordance  with  the  procedures  of  section  5* 

Signalling  messages  sent  by  stimulus  mode  terminals  to  the  network  are 
generated  as  a  direct  result  of  actions  by  the  terminal  user  (e.g.  handset  lifted) 
and  in  general  do  little  more  than  describe  the  event  which  has  taken  place  at  the 
man-machine  interface.  Similarly  signalling  messages  sent  by  the  network  to  terminals 
operating  in  the  stimulus  mode  contain  explicit  instructions  regarding  the  operations 
to  be  performed  by  the  terminal  (e.g.  connect  B-channel,  start  alterting,  etc.). 

Stimulus  mode  terminals  are  not  expected  to  maintain  a  record  of  the  state 
of  any  call  which  Is  currently  supported  since  they  have  a  master-slave  relationship 
with  the  network.  However,  stimulus  mode  terminals  are  expected  to  retain  the 
following  information  : 

1)  Whether  or  not  the  terminal  is  currently  alerting  (Note  -  this  information 
is  required  to  determine  the  correct  message  to  be  generated  when  the 
handset  is  lifted  i.e.  SETUP  or  CONNECT). 

2)  The  current  condition  of  the  switchhook  i.e.  on  or  off  (Note  -  this 
information  is  required  to  determine  how  to  respond  to  a  SETUP  message). 

The  possible  enhancement  of  these  procedures  to  support  additional 
capabilities  such  as  multi-line  or  switchhookless  operation  (see  Appendix  1)  is  for 
further  study. 

The  following  sections  describe  the  detailed  application  of  the  circuit- 
switched  call  control  procedures  to  Type  1  stimulus  mode  terminals.  For  Type  2 
terminals,  the  procedures  are  identical  except  that  call  reference  is  generated  in 
accordance  with  the  procedures  of  5  5.  Table  6-1  summarizes  the  principle 
operations  whilst  Figures  6-1,  6-2  and  6-3  show  the  information  flows  for  a  simple 
call. 


The  call  is  initiated  by  activating  the  suitchhook  of  the  originating 
terminal,  which  then  generates  a  SETUP  message  with  a  dummy  call  reference.  This 
message  must  contain  a  Bearer  Service  Identification  Information  Element  to  inform 
the  network  of  the  type  of  call  being  requested  and  may  contain  a  Switchhook 
information  element.  The  network  sends  back  to  the  user  either  a  SETUP  ACKNOWLEDGE 
or  a  CALL  SENT  message  indicating  which  B-channel  is  to  be  used  for  the  call 
(§  5. 1.1.1). 

6.1.2  Call  information  sending 

If  there  is  no  Keypad  information  element  in  the  SETUP  message,  the  network 
assumes  that  overlap  procedure  is  used  for  sending  the  call  information.  The  SETUP 
ACKNOWLEDGE  message  will  contain  an  information  element  which  may  cause  the  terminal 
to  initiate  the  proper  prompt  (e.g.  dial  tone,  screen  message)  indicating  that 
dialling  can  start.  The  dial  digits  are  sent  as  Keypad  information  element  in 
INFORMATION  messages.  When  the  network  receives  the  first  INFORMATION  message 
containing  keypad  information  element  it  sends  an  INFORMATION  message  to  the  terminal 
instructing  it  to  stop  the  local  prompt.  The  network  may  optionally  acknowledge  each 
message  by  sending  an  INFORMATION  message  with  a  Keypad  echo  information  element. 

The  Network  determines  that  dialling  has  finished  either  by  analysis  of  the  digits  or 
by  receipt  of  an  end  of  dialling  indication  as  defined  by  the  local  network 
procedures  (e.g.  a#  character). 

An  INFORMATION  message  may  also  contain  the  called  party  address  en-bloc, 
as  Keypad  information  element;  this  is  mainly  applicable  when  the  user  invokes  a 
dialling  facility  (e.g.  abbreviated  address  stored  in  the  terminal,  last  dialled 
number) . 


If  the  SETUP  message  contains  sufficient  Keypad  information  for  call 
establishment,  then  en-bloc  procedure  should  be  assumed.  The  network  then  sends  a 
CALL  SENT  message  to  the  terminal,  containing  the  B-channel  to  be  used. 

6.1.3  Call  confirmation 

When  the  terminal  has  received  the  CALL  SENT  message,  it  may  give  a  local 
call  progress  Indication  (tone,  screen  message).  When  the  originating  exchange 
receives  an  indication  that  the  terminating  exchange  has  received  its  request  for  a 
call  set  up,  it  sends  an  ALERTING  message  to  the  calling  terminal.  The  ALERTING 
message  may  contain  network  dependent  optional  stimulus  elements.  The  terminal  then 
stops  the  possibly  locally  generated  call  progress  indication  (tone  or  other  user 
indication) ,  and  may  turn  on  a  local  indication  of  the  alterting  condition  at  the  far 
end. 

6.1.4  Call  connected 

The  originating  exchange  sends  a  CONNECT  message  to  the  calling  terminal 
when  it  gets  an  indication  that  the  call  is  accepted  and  answered  at  the  remote  end. 
This  message  may  also  contain  Display  information  element  provided  by  the  network 
(e.g.  charging  rate,  address  of  the  connected  terminal).  Upon  receipt  of  this 
message,  the  terminal  must  turn  off  its  possible  local  indication  of  the  alerting 
condition  at  the  far  end. 


The  network  will  send  a  SETUP  message  containing  at  least  the  call  reference, 
a  bearer  service  identification  and  the  B-channel  specification.  The  message  may  also 
contain  optionally  the  signal  information  element  Aler ting-on. 

The  terminal  checks  the  bearer  service  identification  and,  if  not  compatible, 
discards  the  complete  message. 

If  the  SETUP-message  contains  a  Display  information  element,  the  associated 
IA5  characters  shall  be  displayed  to  the  user.  Any  Signal  information  element(s) 
will  also  be  acted  upon  in  the  normal  manner. 

If  the  terminal  is  able  to  provide  the  service  indicated,  it  should  return 
an  ALERTING  message  or  directly  a  CONNECT  message.  This  message  will  include  the 
call  reference  chosen  by  the  network  and  the  Terminal  capabilities  information  element. 
It  may  display  any  Display  information  contained  in  the  SETUP  message  and  may  start 
alerting  in  response  to  the  signal  information  element  (Aler ting-on) . 


All  other  information  elements  are  to  be  ignored, 
negotiation  of  B-channela. 


There  will  be  no 


On  an  optional  basis,  the  network  may  choose  not  to  instruct  the  terminal 
to  alert  until  after  it  has  been  informed  of  the  terminals  capabilities .  In  this 
case,  the  information  element  signal  (Alerting-on)  is  not  contained  in  the  SETUP 
message.  Specific  alerting  instructions  are  sent  in  an  INFORMATION  message  after 
receipt  of  the  ALERTING  message. 

When  the  terminal  goes  "off  hook”  a  CONNECT  message  is  sent  to  the  network. 
This  message  must  contain  the  dummy  value  of  the  call  reference  and  may  contain  the 
Svitchhook  information  element. 

If  the  terminal  responds  to  a  SETUP  message  with  a  CONNECT  message,  it 
shall  include  the  original  call  reference  (as  chosen  by  the  network)  and  the 
Terminal  capabilities  Information  element. 

The  network  sends  a  CONNECT  ACKNOWLEDGE  message  including  the  original  call 
reference  (the  one  in  SETUP),  the  B-channel  specification  and  the  Signal  information 
element  ( Alert ing-off) .  The  terminal  then  connects  to  the  B-channel  Indicated. 


The  procedures  described  in  9  5.2  should  be  applied  to  stimulus  mode 
terminal  operation  in  the  following  manner  : 

a)  SETUP  messages  originated  by  a  terminal  should  contain  a  user-to-user 
facility  request  indicating  that  stimulus  mode  operation  is  required; 

b)  for  calls  in  which  the  above  facility  is  requested,  user-to-user  information 
should  be  conveyed  in  the  following  manner  : 

1)  via  Keypad  information  elements  in  the  SETUP  message  generated  by  a 
stimulus  mode  terminal. 


2)  via  Display  information  elements  in  the  SETUP  message  sent  to  the 
called  terminal, 

3)  via  Keypad  information  elements  in  INFORMATION  messages  generated  by 
a  terminal  (Note  :  this  information  will  be  delivered  to  the  remote 
terminal  via  Display  elements  within  USERINFO  messages), 

4}  via  Display  information  elements  in  ALERTING,  CONNECT,  USER  INFO, 
DISCONNECT  or  RELEASE  messages. 


User  action 


•"Lift  handset" 
when  terminal  is 
not  ringing 


•"Lift  handset" 
when  terminal  is 
alerting 


Message  generated  by  terminal  operating  in  the  stimulus  mode 


SETUP,  /  Call  reference,  SI_/  (Signal  off-hook) 

Notes 

1.  For  simple  terminals  only  capable  of  terminating  one 
B-channel  at  a  time,  a  dummy  call  reference  (which  is 
reserved  exclusively  for  this  type  of  terminal)  shall  be  used. 

2.  If  the  terminal  can  only  make/accept  calls  on  a  single 
B-channel,  then  that  B-channel  identity  will  be  included  in 
the  SETUP  message. 

3.  Any  information  keyed  in  by  the  user  while  the  handset  is 
on-hook  will  also  be  sent  in  the  SETUP  message  as  Keypad 
information  when  the  handset  is  lifted. 

CONNECT,  /“ Call  reference_7  (Signal  off-hook) 

Notes 

1.  See  Note  1  above  on  call  reference. 

2.  The  terminal  is  assumed  to  be  aware  that  it  is  alerting 
prior  to  the  off-hook  condition. 


•"Handset  replaced"  DISCONNECT  /“Call  reference_7 
No  tea 

1.  See  Note  1  above  on  call  reference. 

Key  depressed  INFORMATION  /“Call  reference_7  (Keypad  information) 

Notes 

1.  Sea  Note  1  above  on  call  reference. 

2.  The  Keypad  information  element  contains  the  corresponding 
IAS  character  of  the  key  depressed. 


•  Or  equivalent  action. 

/~x  7  Mandatory  information  element, 
(y)  Optional  information  element. 
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User  action 


Message  generated  by  terminal  operating  in  the  stimulus  mode 


Special  keys/pre- 
programmed  keys 
(for  supplementary 
services) 

These  keys  generate  the  INFORMATION  message  containing  : 

a)  appropriate  supplementary  service  stimulus  information 
element,  see  §  6.5, 

b)  Keypad  information  element. 

Notes 

1.  Both  messages  will  have  a  call  reference  set  according  to 
the  rules  described  above. 

2.  In  the  case  of  b) ,  the  Keypad  information  element  will 
contain  the  sequence  of  IA5  characters  which  the  user  would 
have  had  to  key- in  to  request  the  supplementary  facility  if 
the  special  key  had  not  been  implemented . 

Message  received 

Terminal  action 

SETUP 

Perform  simple  compatibility  checking  using  the  bearer  service 
identification  and  channel  identification  information  elements. 
If  the  compatibility  check  la  positive,  the  terminal  will 
return  an  ALERTING  message  using  the  call  reference  contained 
in  the  SETUP  message. 

SETUP  ACKNOWLEDGE, 
CALL  SENT,  CONNECT 
ACKNOWLEDGE 

The  terminal  attaches  to  the  B-channel  indicated  in  the 

message. 

INFORMATION 

(Display) 

The  IA5  information  contained  in  the  Display  information 
element  is  displayed  by  the  terminal. 

ALERTING 

May  be  used  to  provide  an  audible  or  visual  indication  that 
far  end  alerting  has  begun. 

CONNECT 

May  be  used  to  provide  audible  or  visual  indication  that  far 
end  connect  has  occurred. 

i 

DISCONNECT 

No  action  taken.  DISCONNECT  may  be  used  to  provide  an 
indication  of  call  cleared. 

RELEASE 

] 

Disconnect  from  B-channel  and  send  RELEASE  ACKNOWLEDGE. 

Any  message 

The  terminal  will  take  the  appropriate  action  to  Display  and 
Signal  information  elements  which  may  be  contained  in  any 
message  type. 

INFORMATION 
(Stimulus 
information 
elements ) 

The  terminal  will  take  the  specific  action  indicated  in  the 
stimulus  information  element.  See  i  6.5. 

Procedures  for  call  clearini 


Call  clearing  procedures  have  been  simplified  for  the  stimulus  mode 
terminals.  Clearing  procedures  are  described  in  §§  6.4.1  and  6.4*2  and  shown  in 
Figure  7-3. 


Call  clearin 


the  terminal 


The  user  initiates  call  clearing  by  replacing  the  svitchhook  (or  equivalent) 
The  user  equipment  generates  a  DISCONNECT  message.  The  network  responds  to  the 
DISCONNECT  message  by  sending  a  RELEASE  message  to  the  user.  Upon  receipt  of  the 
RELEASE  message,  the  terminal  detaches  from  the  B-channel  and  generates  a  RELEASE 
ACKNOWLEDGEMENT  in  accordance  with  the  procedures  in  §  5.1.3. 


The  network  initiates  clearing  by  sending  a  DISCONNECT  message  to  the  user 
When  the  user  replaces  the  switchhook  (or  equivalent),  a  DISCONNECT  message  is  sent 
to  the  network.  After  the  terminal  generates  the  DISCONNECT  message,  the  procedures 
are  as  described  in  §  6.4.1.  If,  after  receipt  of  a  DISCONNECT  message,  the  user 
does  not  replace  the  switchhook  within  the  prescribed  period  (T30 5),  the  procedures 
in  S  5. 1.3- 2  are  invoked. 

Stimulus  information  elements 


A  provisional  list  of  information  elements  and  their  definitions  is 
contained  in  this  section.  These  information  elements  may  be  used  for  stimulus 
signalling.  The  precise  meaning  and  application  of  those  elements  which  are  not 
described  in  5§  5  and  6.1  through’ 6.4  of  th±3  Recommendation  is  for  further  study. 

Coding  space  for  additional  stimulus  information  elements  has  been  reserved 
in  §  4.  Possible  assignment  of  the  reserved  codes  to  the  stimulus  information 
elements  in  this  section  which  do  not  appear  in  §5  5  or  6.1  through  6.4  is  for 
further  study.  The  information  elements  which  have  been  coded  in  §  4  are  marked  with  * 


This  information  element  from  the  terminal  to  the  network  indicates  the 
billing  method  (reverse  charging,  third  number  etc.)  to  be  used  for  a  given  call. 


This  information  element  from  the  terminal  to  the  network  specifies  that 
the  call  is  requesting  a  service  specified  by  the  information  contained  in  this 
information  element. 


This  information  element  from  the  terminal  to  the  network  reports  whether 
the  terminal's  capabilities  match  the  bearer  service  identification  in  the  SETUP 
message.  This  indication  can  take  one  of  three  forms  : 


1)  terminal's  capabilities  match  the  bearer  service  identification; 
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2)  terminal's  capabilities  do  not  match  the  bearer  service  Identification; 

3)  terminal's  capabilities  match  the  bearer  service  identification  and  terminal 
can  accept  the  call. 

The  third  response  is  optional  for  intelligent  terminals.  The  network 
must  be  capable  of  interfacing  with  terminals  which  do  not  provide  information  on 
whether  they  can  accept  the  present  call. 


This  information  element  is  sent  from  the  terminal  to  the  network  to 
indicate  that  the  user  wishes  to  place  his  current  call  on  hold,  and  accept  the 
incoming  call  which  generated  the  signal  information  element  (Call  waiting  tone  on) 


This  information  element  from  the  terminal  to  the  network  requests  a 
conference  call.  After  receipt  of  the  conference  information  element,  the  network 
should  expect  to  receive  a  Keypad  information  element  containing  the  address  of  the 
connection  to  be  added. 
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This  information  element  is  sent  from  the  terminal  to  the  network  to 
indicate  that  a  call  is  to  be  placed  to  a  closed  user  group.  This  information 
element  will  be  followed  by  a  Keypad  information  element,  containing  the  identity  of 
the  closed  user  group. 

6. 5.1. 8  Feature  activation  information  element 


This  information  element  from  the  terminal  to  the  network  is  used  to  convey 
requests  for  features  that  are  not  included  in  the  fixed  function  signal  set.  A 
feature  activation  information  element  is  assignable  to  any  function,  allowing 
flexibility  in  offering  features  for  stimulus  mode  terminals.  The  Feature  activation 
information  element  can  be  used  to  provide  supplementary  features  on  a  system  specific 
or  national  option  basis. 

M.1.9  Hold  Information  element 


This  information  element  from  the  terminal  to  the  network  is  a  request  to 
place  the  current  call  on  hold.  Recovery  from  Hold  is  for  further  study. 

6.5.1.10  Keypad  information  element 


This  information  element  from  the  terminal  to  the  network  is  used  to  convey 
information  from  the  terminal 'a  keypad. 


6.5.1.11 


The  use  of  this  information  element  Is  as  defined  In  i  T.T..1. 
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6.5.1.12  Transit  network  select  information  element 

This  inforaation  element  from  the  terminal  to  the  network  indicates  the 
transit  network  chosen  by  the  user  to  provide  transmission  facilities  for  use  with  a 
given  call. 

6.5*1.13  Self -test  response  Information  element 

This  information  element  from  the  terminal  to  the  network  is  in  response  to 
the  Self-test  inquiry  signal.  It  enables  the  terminal  to  report  the  results  of  its 
self-test  to  the  network.  The  nature  of  the  terminal  self  test,  if  provided,  is  for 
further  study.  If  no  self-testing  capability  is  provided  by  the  terminal  it  will  so 
indicate  via  this  information  element. 

6.5.1.14  Terminal  capabilities  information  element 

This  information  element  is  sent  to  the  network  as  part  of  the  ALERTING  or 
CONNECT  message  in  response  to  the  functional  SETUP  message.  It  indicates  to  the 
network  that  it  is  a  stimulus  mode  terminal. 

6.5.1.15  Suspend  Information  element 

The  use  of  this  information  element  is  defined  in  §  5.1.4. 

6. 5. 1.16  Switchhook  information  element 

This  information  element  from  the  terminal  to  the  network  indicates  a  change 
in  the  switchhook  state. 

6.5.1.17  Switchhook  response  information  element 

This  information  element  from  the  terminal  to  the  network  reports  the 
switchhook  status  as  requested  by  a  Switchhook  Inquiry  information  element  from  the 
network. 

6. 5.1.18  Terminal  capabilities  response  element 

This  information  element  from  the  terminal  to  the  network  is  a  response  to 
the  Terminal  capabilities  inquiry  information  element.  It  contains  a  list  of  the 
bearer  services  the  terminal  is  capable  of  handling. 
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6.5.1.19  Transfer  information  element 

This  information  element  from  the  terminal  to  the  network  is  a  request  to 
transfer  the  current  call.  After  receiving  this  information  element,  the  network 
should  expect  to  receive  a  Keypad  information  element  containing  the  address  where  the 
call  is  to  be  transferred. 

6.5.2  Information  elements  from  network  to  terminal 

6. 5.2.1  Bearer  service  identification  information  element 

This  information  from  the  network  to  the  terminal  informs  the  terminal  of 
the  bearer  service  associated  with  an  incoming  call. 
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6. 5. 2. 2  Display  Information  element 


This  information  element  from  the  network  to  the  terminal  contains 


Information  to  be  displayed  on  the  terminal's  display.  The  message  contains  IA5 
characters.  Escape  sequences  for  screen  controls  (cursor,  clearing  screen,  etc.)  are 
for  further  study. 


6.5. 2. 3 


This  Information  element  from  the  network  to  the  terminal  causes  the 
terminal  to  activate  an  Indicator  associated  with  the  feature  activation  function. 
An  example  of  a  Feature  indication  is  the  lighting  of  a  lamp  in  response  to  the 
pressing  of  a  feature  button. 


6. 5. 2.4 


This  information  element  from  the  network  to  the  terminal  acknowledges 
receipt  of  a  Keypad  information  element.  This  information  element  is  used  to  provide 
visual  or  audible  feedback  to  the  terminal  user  to  indicate  that  address  digits  or 
feature  codes  have  been  received  by  the  network.  It  does  not  need  to  be  interpreted 
by  the  terminal. 


6.5. 2. 5 


sset  information  element 


This  information  element  from  the  network  to  the  terminal  causes  the 
terminal  to  be  reinitialized.  The  terminal  resets  layer  three  signal  processing 
and  deactivates  all  indicators. 


6.5. 2. 6 


This  information  element  from  the  network  to  the  terminal  causes  the 
terminal  to  perform  a  self- test. 


6. 5. 2. 7 


This  information  element  from  the  network  to  the  terminal  tells  the 
terminal  to  generate  alerting  signals,  call  progress  tones  or  other  indications 
informing  the  user  of  an  incoming  call  or  about  the  current  status  of  a  call.  The 
data  field  of  this  information  element  provides  for  distinctive  alerting  signals 
allowing,  for  example,  use  of  different  ringing  patterns  to  indicate  an  on-premises 
versus  an  off -premises  call.  Call  progress  indications  are  :  dial  tone,  ringing, 
busy,  reorder,  confirmation  of  a  request,  call  answered,  call  waiting,  and  off-hook 
warning. 


6.5. 2. 8 


itlon  element 


This  Information  element  from  the  network  to  the  terminal  requests  the 
status  of  the  terminal's  switchhook. 


6.5.2. 9 


This  information  element  from  the  network  to  the  terminal  inquires  as  to 
the  capabilities  of  the  terminal.  The  terminal  responds  with  the  Terminal  capability 
response  information  element  which  reports  the  bearer  services  that  the  terminal*  can 
handle. 


/«**  91 


■■v-sS 


.*\  -y- 


-y  -jrPTT^t  if  J-*  <L'  P  ^  V%v.  -jvv*  s.'  .  > 


■-■%.  ,™*W  '  ■%  -,~w  ; 


w 


N 


% 

V 


A. 342 


-  123  - 


Originating 

terminal 


Originating 

network 


Torsi no I 
connects  to 
S-chnnnol 


Koto  1 


S«*  Fig. In  -  -  - 
lot  IMktt4|MNt 

procedures . 


(SI, Ref  <dummy+>  J (Svitchhook 
<OFF  H00K>)  (Terminal  Capabil¬ 
ities^  sr.TUP  /M.'rMtwt/.nrt 

l«.r  <dummyf  >,  B-cbannel] 
(Signal (DIAL  0N>) 

INrUNHATIlW 


l«»f  <duamyt>](  KEYPAD  or  CALL 
INFORM.) 


INFIMMATtlM 


(RefCdummjrf >]  ( . 


iNroniATiiiH 


tNmuwiUen 


cam.  swrr 


1  ■sl.< dumnjrf>j^  DISPLAI ,  CALL 
INFORMATION) 


km 

|  m  |  tsondatorf  Information 
•Itwnt 

(  f  )  opd on*  1  Information 
element 

See  Note  1 
t  See  Note  1  (b) 


Th«  MM  of  thlo  MOMBO  at 
till!  flow  of  tho  call  It  t 
Httnoth  notion.  Information 
oltooott  which  cnwM  ho 
con«oyo4  include  K  Kt  pan 
(ECHO  and  Signal  tDIAXT  0FF>  . 


FI0UREJ7-2/Q.930 

Overlap  procedures  for  basic  e»n  establishment 


n 


n\ 

*>! 

n 


91 


V  *- 

!* 


Note 8  to  Figures  7-1.  7-2  and  7-3/Q.930 


1. (a)  The  mandator  and  optional  elements  shown  in  each  message  are  those  necessary 

for  simple  terminals.  Other  information  elements  would  also  be  included  in 
accordance  with  Q. 930(1. 451)  but  could  be  ignored  by  the  simple  terminal. 

(b)  The  "dummy"  call  reference  is  used  for  Type  1  terminals  only.  Type  2 
terminals  use  the  call  reference  in  the  usual  Q. 930(1. 451)  manner. 

2.  It  is  intended  that  the  message  elements  which  are  essential  for  simple 
terminal  operation  should  be  included  at  the  beginning  of  each  message. 

3* (a)  The  information  element  "Signal<Ringing  on>"  may  be  optionally  included  in 
this  message.  It  is  envisaged  that  this  information  element  would  not  be 
used  for  Public  Network  access  but  could  be  employed  for  terminal  to  PBX 
signalling. 

(b)  If  the  information  element  "Signal<Ringing-on>"  was  sent  in  the  ALERTING 

message,  then  "Signal<Ringing-off>"  should  be  included  in  the  CONNECT  message. 

4*  A  Display  information  element  may  be  Included  in  any  message  sent  by  the 

network  to  the  terminal.  The  nature  of  the  information  to  be  displayed  is  a 
network  dependent  matter. 

5.  INFORMATION  messages  may  be  sent  by  the  network  or  terminal  at  any  time  in  a 
call.  This  message  may  be  used  to  convey  information  elements  such  as  Keypad 
(terminal  to  network).  Signal,  Display  (network  to  terminal). 

6.  The  information  element  "Signal<Alerting-on>''  may  be  included  in  the  SETUP 
message  to  indicate  a  particular  alerting  pattern.  The  alerting  action  is 
autonomously  terminated  by  the  terminal  when  it  goes  off-hook  and  sends  a 
CONNECT  message. 

7.  In  clearing  procedures  in  Figure  7-3/Q-920,  the  sending  of  a  DETACH  message 
is  not  precluded. 

8.  (a)  If  the  SETUP  message  included  the  information  element  "Signal<Alerting-on>", 

then  the  terminal  will  generate  a  local  alerting  signal  in  conjunction  with 
returning  the  ALERTING  message. 

(b)  If  the  SETUP  message  did  not  include  the  information  element 

"Signal<Alerting-on>",  then  the  terminal  will  simply  return  the  ALERTING 
message  with  the  information  element  "Terminal  capabilities"  to  inform  the 
network  that  it  is  a  simple  terminal.  The  network  may  instruct  the  terminal 
to  begin  alerting  by  sending  the  information  element  "Signal<Alerting-on>" 
in  the  INFORMATION  message. 
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APPENDIX  I 

This  Appendix  is  provided  only  for  information.  It  shows  only  one 
possibility  of  solving  the  problem  hereunder  mentioned.  Further  study  is  required 
to  evaluate  all  the  implications . 

An  example  modification  to  stimulus  mode  call  control  procedures  to  simplify 
terminal  requirements  and  provide  for  enhanced  capabilities  such  as  multi-line 
operation*  is  provided. 

The  simplifed  call  control  procedures  in  §  7  require  the  stimulus  terminal 
to  generate  messages  based  on  knowledge  of  the  status  of  its  switchhook  and  of  its 
alerting  mechanism.  This  requirement  may  limit  the  design  flexibility  for  certain 
terminal  types  such  as  multi-line  terminals.  This  Appendix  shows  example 
modifications  to  the  procedures  which  will  permit  multiple  line  operation  without 
requiring  the  terminal  to  keep  track  of  terminal  states. 

1.  Call  establishment  at  originating  exchange 

Procedures  as  described  in  §  7.1  apply. 


2.  Call  establishment  at  the  destination  exchange 

The  procedures  of  i  7.2  apply  with  the  following  exception  :  the  network 
interprets  the  CONNECT  message  based  on  its  knowledge  of  current  terminal  status. 

In  cases  in  which  the  "line"  selected  by  the  user  is  different  than  the  line  the 
network  has  instructed  the  terminal  to  alert,  the  CONNECT  message  is  interpreted  as 
a  request  for  service  (SETUP)  and  the  originating  call  procedures  are  followed.  An 
example  case  in  which  these  procedures  apply  is  shown  in  Figure  Appendix  1/Q.930. 


A  multi-line  terminal  i3  a  terminal  which  terminates  on  a  single  access  facility 
but  which  has  the  ability  to  originate  or  terminate  calls  from  or  to  multiple 
ISDN  addresses  which  may  also  appear  at  other  access  facilities. 
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